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UNIX-Workstations sind als Sammlerobjekte in der 
Retrocomputer-Szene nicht so beliebt wie die klas- 
sischen Homecomputer von Atari oder Commodore. 
Trotzdem gibt es nicht wenige Freunde alter Rechner, 
die sich dieser Geräteklasse angenommen haben. 
Kein Wunder - jeder Hersteller hat eigene technische 
Innovationen in den Maschinen verbaut. Mehr noch: 
Die heute dominante Technik hat ihre Wurzeln in den 
RISC-Workstations der 1990er-Jahre. Viele der da- 
mals tonangebenden Ingenieure und Manager sind 
noch heute aktiv und mischen bei aktueller Technik 
mit. Wir stellen in dieser Ausgabe die wichtigesten 
Hersteller und Systeme vor, geben Tipps zur Instand- 
setzung und Erweiterung und schauen uns auch an, 
was Atari und AMIGA in Bezug auf UNIX zu bieten ha- 
ben. 


Das ist natürlich nicht alles. Wir stellen selten be- 
schriebene Taschenrechner von Texas Instruments 
vor, beschreiben aktuelle Nachbauten alter Rechner 
und werfen einen Blick auf den ersten Commodore- 
Rechner mit dem SID-Chip. Auch die Praxis kommt 
nicht zu kurz, denn wir zeigen, wie Atari-Programme 
auf einem PC kompiliert und assembliert werden kön- 
nen, nutzen den Apple Il zur Temperaturmessung und 
konfigurieren einen universellen Netzwerkserver. Be- 
sonders stolz sind wir, dass uns ein englischsprachiger 
Artikel zum wenig bekannten Sinclair QLAN erreicht 
hat, den wir in einer deutschen Übersetzung bringen. 


Zu dieser Ausgabe gibt es auch wieder eine Heft-CD 
als Image zum Download, die viele Programme und 
zusätzliche Infos enthält. 


Haben wir etwas vergessen? Ja! Mit dieser Ausgabe 
feiert die LOAD ihr 10-jähriges Bestehen, auch wenn 
es erst die 8.Ausgabe ist. Ein wenig Geschichte der 
LOAD finden Sie auf den Seite 79 und 83, ausführlich 
feiern werden wir uns aber erst in der 10. Ausgabe im 
Jahr 2024. 


Viel Spaß also mit dieser Ausgabe der LOAD wünscht 
Ihnen 


Ihr Georg Basse 
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Alle Links der Artikel in dieser Ausgabe finden Sie unter 
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Veranstaltungen 


mit Terminen der Retrocomputer-Treffen 2022 veröffent- 
licht. Doch leider sind aufgrund der gesetzlichen Auf- 
lagen zur Pandemiebekämpfung Veranstaltungen noch immer 
nicht verbindlich zu planen. Vielleicht hat sich die Lage mit dem 
Erscheinen dieser Ausgabe bereits verbessert. 
Darum Augen auf - viele Veranstalter warten gespannt darauf, 
dass es wieder losgehen kann. Hier ein paar Beispiele: 


(3 ern hätten wir an dieser Stelle einen randvollen Kalender 


Das Alternative Computermeeting in Flechtorf zwischen 
Wolfsburg und Braunschweig heißt im Mai oder Juni alle 
historischen 8-Bit Rechner, ältere Konsolen, Amigas, Ataris, 
MorphOS-Rechner und PPC-Macs sowie X86er mit UAE und 
AROS willkommen. Wer einen Vortrag halten will, ist herzlich dazu 
eingeladen und kann sich deswegen beim Veranstalter melden. 


Auf dem Amiga-Meeting Neumünster treffen sich Besitzer von 
Classic-Amiga, Amiga OS4, MorphOS, Emulatoren oder AROS. 
Die Veranstaltung ist auch offen für andere Classic-Systeme. Das 
nächste Treffen ist vom 03. bis 05.11.2022 geplant. 


Die Classic Computing 2022, das große Treffen des Vereins 
zum Erhalt klassischer Computer und eines der größten Treffen 
in Deutschland soll vom 08. bis 11. September in Lingen an der 
Ems stattfinden. 


Die DoReCo findet mehrmals im Jahr in Dortmund statt und ist 
ein Treffen für Freunde alter und neuer Video- und Computerspiele. 
Für 2022 waren zum Redaktionsschluss noch keine Termine 
bekannt. Zusammen mit dem Heinz Nixdorf Forum in Paderborn 
ist außerdem ein zweitägiges Retrocomputer-Festival geplant, der 
Termin steht noch nicht fest. 


Auf der Fujijama treffen sich die Liebhaber der 8-Bit- 


Atarirechner. Die Veranstaltung wird vom User Club ABBUC 
veranstaltet. 


Adressen und Links 


Der Vintage Computer Club e.V. veranstaltet mit der [connected] 
und der Interface Kiel zwei Treffen im Norden der Republik. Dort 
wird klassische Computertechnik genutzt, gepflegt und präsentiert 
und Erfahrungen werden ausgetauscht. 


Die Lange Nacht der Computerspiele findet in der Universität 
Leipzig statt und präsentiert auf 4 Etagen neue und alte 
Computerspiele. 


Die Luhecon findet mehrmals jährlich in Winsen (Luhe) statt 
und ist ein offenes Treffen für alle Freunde klassischer 
Rechnertechnik. 


Der Marburger Stammtisch ist ein unkommerzielles und 
familiäres Treffen retrobegeisterter Technikfreaks aller Couleur. 
Der Spaß an der Arbeit mit alter Computerhard- und software steht 
im Mittelpunkt. 


Die Retropulsiv ist eine halbjährlich an der Hochschule 
Augsburg stattfindende Veranstaltung zum Thema antiquierte 
Computer aus den Anfängen der PCs in den 1970ern bis hin zu 
Spielekonsolen aus den 1990ern. 


Der Retrocomputer-Treff Niedersachsen veranstaltet drei- bis 
viermal im Jahr ein ganztägiges Treffen in der Region Hannover. 
Das Treffen ist nicht auf bestimmte Hersteller festgelegt. 


Das Vintage Computer Festival Berlin findet Anfang Oktober 
im Technikmuseum Berlin statt und präsentiert in einer großen 
Ausstellung historische Computer. Die Veranstaltung bietet dazu 
eine Reihe interessanter Vorträge. 


Es lohnt sich also, hin und wieder auf die Webseiten der 
Veranstalter zu schauen. Termine werden dort kurzfristig bekannt- 
gegeben. 


Alternatives Computer Meeting 
Dorfgemeinschaftshaus Flechtorf, Alte 
Braunschweiger Str. 21, 38165 Lehre OT 
Flechtorf 
http://acm.members.vzekc.de 

Amiga-Meeting Neumünster 


Kiek in!, Gartenstraße 32, 24534 
Neumünster 


http://www.amigameeting.de/ 

Classic Computing 2022 
Halle IV, Kaiserstraße 10a, 49809 Lingen 
https://www.classic-computing.org/cc2022- 
hauptseite/ 

DoReCo 


AWO Dortmund, Syburger Strasse 75, 
44265 Dortmund 


http://\www.doreco.de/ 
DoReCo Party 


Schützenhalle Anröchte, Altenmellrich, Alter 
Kirchweg 2, 59609 Anröchte 


http://www.doreco.de/ 

HomeCon 
Alte Schule — Eingang Haggasse — Großer 
Saal, EG Taubengasse 3, 63457 Hanau 
(Großauheim) 

Fujijjama 
Schützenhausweg 11, 08485 Lengenfeld 
http://abbuc.de/-atarixle/fuji/2020/ 


Interface Kiel 


Jugendhaus Klausdorf ( 1. + 2. OG), 
Dorfstraße 101, 24222 
Schwentinental/Klausdorf 


http://vccev.de/events 

Lange Nacht der Computerspiele 
LIPSIUS-Bau, Karl-Liebknecht-Str. 145 in 
04277 Leipzig 

LuheCon 
Marstall, Schloßplatz 11, 21423 Winsen an 
der Luhe 

Marburger Stammtisch 


Ortenberg-Gemeinde e.V., Rudolf-Bultmann- 
Straße 7 


http://www.marburger-stammtisch.de 
Retro Daddel Day Wuppertal 
Blumenstr. 16, 42119 Wuppertal 
http://www.radio-paralax.de/ 
RETROLUTION 
Kulturhalle Steinheim, Ludwigstraße 67, 
63456 Hanau (Steinheim) 
RETROthek Karlsruhe 
Aussteller-Voranmeldung bitte unter 
retrothek@kultur.karlsruhe.de 


Stadtbibliothek im Neuen Ständehaus, 
Ständehausstraße 2, 76133 Karlsruhe 


RETROpulsiv 


Hochschule Augsburg, An der Hochschule 
1, 86161 Augsburg 


www.hs-augsburg.de/Service/ 
Impressum*anmeldung@retropulsiv.de 


Retrotreff Niedersachsen 


Freizeitheim Döhren, An der Wollebahn 1, 
30519 Hannover 


https://www.classic- 
computing.org/tag/hannover/ 
Uni Mainz 
Computersammlung der Universität 
https://www.classic- 
computing.org/veranstaltungskalender 
Vintage Computer Festival Berlin 


Deutsches Technikmuseum (Historische 
Ladestraße), Möckernstr. 26, 10963 Berlin 


www.vcfb.de 
VCFe 


Kulturzentrum Trudering, Wasserburger 
Landstraße 32, 81825 München 


https://www.vcfe.org 


Die CD-ROM zum Heft 


Wir berichten in der LOAD oft über 
Software und Tools für klassische Com- 
puter. Dazu liefern wir Links zu den Down- 
load-Quellen. Doch das Internet ist ver- 
gesslich - manchmal sind wichtige Dateien 
nach einigen Jahren nicht mehr auffindbar. 


Darum gibt es zu dieser Ausgabe der 
LOAD wieder eine CD-ROM, randvoll mit 
Zusatzinfos zu den Artikeln, Bilder, Soft- 
ware und Vielem anderen. Außerdem 
finden sich auf der CD-ROM die PDF Ver- 
sionen der bisher erschienenen Ausgaben 
der LOAD. PC-Nutzer werden sich außer- 
dem über das BIOS Kompendium und 
seine Tools freuen, ein unentbehrliches 
Nachschlagewerk für die Feinheiten der 
unterschiedlichen BIOS-Versionen. 


Die CD-ROM zum Heft gibt es als ISO- 
Image zum Selbstbrennen und in limitierter 
Auflage auf unseren Veranstaltungen. 


Das Passwort zum 
Download lautet: CD2022 


Download: https://www.load-magazin.de/load8 
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Kurz berichtet 


PC-Serial-Loader 


Ursprünglich auf Disketten verteilte Soft- 
ware für den IBM PC sind heute als Disk- 
images im Internet in Hülle und Fülle zu 
bekommen. Um sie zu nutzen, müssen sie 
oft wieder auf reale Disketten geschrieben 
werden. Das kann Probleme mit sich brin- 
gen, wenn der Zielrechner zwar passende 
Floppies, aber keinen Netzanschluss hat, 
der Internet-PC aber keine passenden 
Diskettenlaufwerke. Der PC-Serial Loader 
löst dieses Problem. Es handelt sich um 
eine zweiteilige Software für IBM PCs, die 
Diskimages vom Internet-PC über ein seri- 
elles Nullmodem-Kabel auf den Zielrech- 
ner überträgt und dort auf Disketten 
schreibt. Zuerst ist dabei aber ein Henne- 
Ei Problem zu lösen: Wie kommt das ClIi- 
entprogramm auf den Zielrechner, wenn 
dieser nur Diskettenlaufwerke besitzt? Der 
PC-Serial Loader macht das ähnlich der 
ADTPro Software für den Apple Il oder dem 
Amiga Explorer. Ein in Assembler geschrie- 
bener Inital Loader wird über die Tastatur 
am Zielrechner eingegeben - kein Prob- 
lem, denn er umfasst nur 22 Instruktionen. 
Die Eingabe passiert mittels Nummern- 
block und gedrückter ALT-Taste direkt als 
Bytefolge. Ist der Initial Loader erst einmal 
eingetippt, lädt er den eigentlichen Client 
(die Toolbox) auf den Zielrechner. Nun 
können Diskimages übertragen werden. 
Der Internetrechner erhält dafür ein Win- 
dows-Programm mit grafischer Benutzer- 
oberfläche, das die Win32-API verwendet. 
Das nur etwa 60 KB große GUI-Programm 
läuft unverändert unter allen Windows-Ver- 
sionen seit Windows 95. Unter Linux ist 
WINE als Zwischenschicht erforderlich. 
Das Programm ermöglicht ein Lesen und 
Schreiben von Diskimages mit den Floppy- 
Laufwerken des Zielrechners. Auch Da- 
teien lassen sich in beide Richtungen trans- 
ferieren. 


Links: 


http://www. zotteljedi.de/pc-serial-loader/in- 
dex.html 


RaSCSil 


RaSCSl ist ein virtueller SCSI-Emulator, 
der auf einem Raspberry Pi läuft. Er be- 
steht aus einer Software unter dem Debi- 
an Derivat Raspian und einer Hardware- 
erweiterung, die mit den GPIO Pins des Pi 
verbunden wird. RaSCSI kann mehrere 
SCSI-Geräte gleichzeitig emulieren, bietet 
eine Steuerungsschnittstelle zum An- 
schließen und Entfernen von Laufwerken 
sowie zum Einlegen und Auswerfen von 
Wechselmedien. Mittels Software lassen 
sich virtuelle Laufwerke auf einer SD Karte 
anlegen, SCSI IDs und LUNs zuweisen und 
diese wie echte SCSI-Festplatten durch 


einen Macintosh oder einen Atari TT, eine 
Sun oder DEC Alpha Workstation oder an- 
dere Computer mit SCSI-Anschluss nut- 
zen. Besonderes Schmankerl: Die Soft- 
ware emuliert auch einen DaynaPort-SCSI 
Ethernetadapter und bringt so klassische 
Macintosh- und Atari-Rechner ans Netz. 
Auch ein spezieller Webproxy zur Filterung 
von Webinhalten ist implementiert — da- 
durch verdauen auch alte Web Browser die 
heute meist völlig überladenen Webseiten. 
Ein ausführlicher Erfahrungsbericht zum 
RaSCSI-Adapter erscheint in der nächsten 
Ausgabe der LOAD. 


Links: 
https://github.com/akuker/RASCSI/iki 


Geburtstagskinder 
Apple Quicktime 


About QuickTime... 


Im Dezember 2021 war es drei Jahr- 
zehnte her, dass Apple mit Quicktime den 
Pionier unter den Programmen und For- 
maten für Computervideos auf den Markt 
brachte. Voller Begeisterung saßen die An- 
wender vor ihren Macintosh-Rechnern und 
konnten echte Videos auf dem Monitor be- 
wundern. Nur briefmarkengroß und meilen- 
weit von heutigen 4K-Auflösungen entfernt, 
drangen Videoclips auf Rechner vor, die 
nie zuvor Bewegtbilder gesehen hatten. In 
den 1990er-Jahren und den ersten Jahren 
des neuen Jahrtausends wurde Quicktime 
praktisch überall eingesetzt. Apple setzte 
den Quicktime Player für Windows um, 
auch für andere Plattformen existieren ent- 
sprechende Player, die Quicktime Codecs 
unterstützen. 


Commodore 64 


Im Januar 2022 ist der meist verkaufte 
Heimcomputer weltweit, der Commodore 
64 tatsächlich 40 Jahre alt geworden. Seit 
seiner Vorstellung auf der Winter Consu- 
mer Electronics Show 1982 hat er sich mil- 
lionenfach verkauft, die Schätzungen 
schwanken zwischen 12,5 und 30 Millio- 
nen Exemplaren. Nicht nur seine für die da- 
malige Zeit üppige Speicherausstattung mit 
84 KBytes RAM und seine Videodarstel- 
lung mit dem VID und Soundfähigkeiten mit 
dem dreistimmig polyphonen Soundchip 
MOS Technology SID 6581 machten ihn so 
populär. Vor allem die Erweiterbarkeit durch 
den herausgeführten Adress- und Daten- 
bus machen ihn bis heute zur Plattform für 
Hardware-Ergänzungen aller Art. Eine aus- 
führliche Würdigung des Brotkastens er- 
scheint in der nächsten LOAD. 


Sinclair ZX81 


Etwas verspätete Glückwünsche gehen 
auch an den Sinclair ZX81. Er erblickte im 
März 1981 das Licht der Welt oder besser 
den Nebel der britischen Insel, denn zu- 
nächst war er nur in England über den 
Versandhandel verfügbar. Als Weiter- 
entwicklung des Sinclair ZX80 wurde er als 
günstiger Lerncomputer beworben. Ende 
1981 verkaufte Sinclair dann den ZX81 
auch im übrigen Europa und in anderen 
Ländern der Welt. Bis Ende 1984 setzte 
Sinclair insgesamt etwa 2 Millionen der 
kleinen Geräte ab, darunter auch lizenzierte 
Nachbauten wie dem Timex Sinclair 1000, 
ein besonders in den USA beliebtes Gerät. 


Commodore AMIGA 
1200 und 4000 


Im Oktober 2022 können 
alle AMIGA Fans auf den 30. 
Geburtstag der beiden letzten 
AMIGA-Modelle anstoßen, 
den A1200 und den A4000. Mit 
diesen beiden Modellen führte 
Commodore den leistungs- 
fähigen AGA-Chipsatz ein und 
löste den glücklosen AMIGA 
600 ab. Mit den drei Chips Lisa, 
Alice (Grafik) und Paula 
(Sound) konnte sich die Leis- 
tung des Motorola 68EC020 
(14 Mhz) basierten Rechners 

durchaus sehen lassen. Die 
Produktion des A1200 durch 
Commodore dauerte nur etwa 2 
Jahre und wurde nach der In- 
solvenz des Unternehmens 
zunächst eingestellt. Ab Mai 
1995 nahm die ESCOM-Tochter 
Amiga Technologies dann die 
Produktion wieder auf. Doch 
nach einem Jahr war auch damit 
Schluss, als ESCOM und Amiga 
Technologies ebenfalls Konkurs 
anmelden mussten. 


Atari-Home.DE 
übernommen 


Knapp 23 Jahre ist es her, dass 
atari-home.de das Licht der Welt 
erblickte. Der bisherige Eigen- 
tümer und Betreiber der Seiten 
(Johannes) hat zum Februar 2022 
nun Webpräsenz und Forum an 
den Verein zum Erhalt klassischer 
Computer e.V. übergeben. Johan- 
nes hat fast die Hälfte seines 
Lebens mit atari-home.de ver- 
bracht und hat dafür gesorgt, dass 
diese Domain auch weiterhin ein 
wichtiger Anlaufpunkt für alle Atari- 
Freunde in deutschsprachigen 
Raum bleibt. Der VZEkC e.V. pflegt 

die bestehenden Angebote in 
gewohnter Form unverändert 
weiter. 


Links: 


http://www.atari-home.de 


'Verein zum Erhalt 
iklassischer Computer e.V. 


! Sehr geehrte Vereinsmitglieder, 
sehr geehrte Freunde der Bits & Bytes vergangener Tage 


: Mit dem Jahr 2021 blickt der Verein zum zweiten Mal auf ein Jahr zurück, 
das anders verlief als geplant. Das Corona-Virus hat vieles erschwert und man-! 


!ches unmöglich gemacht und unseren Alltag länger dominiert, als wir es im: 


! Jahr zuvor für möglich gehalten haben. 


Ein wichtiger Teil unseres Vereinslebens sind Veranstaltungen zum Thema: 
!Retrocomputing, sei es als Veranstalter regionaler und überregionaler Treffen: 
toder als Teilnehmer an diesen Meetings. Unser jährliches Highlight, die Clas-! 
isic Computing stand 2021 lange auf der Kippe. Die Pandemielage war schwer! 
!abzuschätzen und auch die Hygienevorgaben der Landesregierungen verän-: 
!derten sich in kurzen Abständen. Umso glücklicher waren wir, dass die Clas-: 
isic Computing 2021 vom 17. bis 19. September im Kulturzentrum Vöhringen: 
! stattfinden konnte wie geplant. Dort zeigten 38 Aussteller an insgesamt 65 Ti-: 
!schen ihre Schätze. Die Ausstellung war am Samstag und Sonntag für die Öf-: 
!fentlichkeit zugänglich, etwa 250 Besucher fanden ihren Weg zu uns. Erstmals! 
ihat der Verein eine Security-Firma beauftragt, die sich um die Einhaltung der: 
:"3G-Regeln" zum Schutz vor der Corona-Pandemie gekümmert hat. Der be-: 
sondere Dank gilt Michael Vogt, der die Veranstaltung vor Ort organisiert hat: 


und für einen reibungslosen Ablauf sorgte. 


! Aber nicht nur die Classic Computing war ein Erfolg, auch regionale Treffen: 
konnten stattfinden. Das Münchberger Bastel- und Retrotreffen hat das Ver-: 
:einsleben ebenso bereichert wie die Retrocomputing-Abende im Stuttgarter: 
!Shack oder der Retrocomputer-Treff Niedersachsen in der Nähe von Hanno-: 
Iver. Weitere Kontaktmöglichkeiten bestanden bei Online-Stammtischen wie! 
dem von Axel und Reinhard. Für das laufende Jahr 2022 sind wir optimistisch, 


. 


; dass unsere Treffen wieder weitgehend unter gewohnten Bedingungen statt-} 
!finden können. Die Planung der Classic Computing in Lingen ist weit fortge-: 


ischritten und auch regionale Treffen finden wieder statt. 


! Anders wird es mit unserer jährlichen Hauptversammlung sein. Nachdem! 
i diese in den Jahren 2020 und 2021 als Online-Veranstaltung abgehalten wur-} 
!de und wir sehr gute Erfahrungen mit dieser Form machen konnten, werden} 
!wir dies auch in den nächsten Jahren beibehalten. Die Erfahrung hat gezeigt,: 
dass auch Wahlen auf diesem Wege erfolgreich durchgeführt werden können. 
! Auf der JHV 2021 wurde der 1. Vorsitzende Stephan Kraus in seinem Amt be-: 
!stätigt. Der langjährige Kassenwart Thomas Linke scheidet aus beruflichen: 
Gründen aus, Nachfolger wurde der bisherige 1. stellvertretende Vorsitzende: 
; Florian Stassen. Norbert Kötting rückt für ihn in den Vorstand nach. Das Amt: 
! des Schriftführers übernimmt Georg Basse von Matthias Krambeck und als! 
ineuer 1. Beisitzer des Schiedsgerichts wurde Bernd Dohr gewählt. Volker Mohr: 
: wurde als Vorsitzender des Schiedsgerichts bestätigt, ebenso Christa Schul-: 


ides als 2. Beisitzerin. 


: Der Verein und seine Aktivitäten erfreuen sich auch an anderen Stellen gro-: 
:ßer Beliebtheit. Im Jahr 2021 konnten wir 46 neue Vollmitglieder und 4 neue: 
!Fördermitglieder gewinnen. Damit zählt der Verein zum Februar 2022 bereits! 
3315 Mitglieder. Auch das Vereinsforum wächst stetig — derzeit sind dort 4.250: 
: Teilnehmer registriert. Seit Bestehen des Forums haben sich 350.000 Beiträ-! 
ige in 26.000 Themen rund um Retrocomputing und Vereinsleben dort gesam-: 
!melt. Wir schätzen uns außerdem glücklich, mit der Übernahme des Forums: 
! Atari-Home.DE eine weitere Community mit 780 Mitgliedern unterstützen zu: 


»können. 


! Spaß bei der Lektüre der LOAD! 


i Der Vorstand des VzEkC 
S. Kraus, N. Kötting, C- Dirks, F. Stassen, G.Basse 


Wir können also optimistisch in die Zukunft schauen. In diesem Sinne — viel: 


Titelthema Workstations 


Eine kleine Geschichte der RISC Workstations 


Oft wird gesagt, die University of California in Berkeley 
gegenüber von San Francisco sei vor allem durch zwei 
Dinge bekannt geworden: LSD und BSD. Die Behauptung 
ignoriert zumindest eine Entwicklung aus dieser Stadt, 
nämlich das Konzept der RISC-Prozessoren. Ohne diese 
wäre der Boom der Workstations in den letzten beiden 
Jahrzehnten des vorigen Jahrhunderts wohl ausgeblieben. 


ersetzen wir uns einmal in die 

Computerwelt der 1960er-Jahre. 

Einige, wenige Großrechner 
(Mainframes) liefen in Banken, Versich- 
erungen, Industrie oder Forschungseinrich- 
tungen. Der direkte Kontakt zu diesen 
großen Eisen war dem Operator vorbehal- 
ten, der gekleidet im weißen Laborkittel die 
Maschine am Laufen hielt. Programmierer 
und Anwender hatten keinen direkten Kon- 
takt — sie gaben ihre Arbeitsaufträge in 
Form von Lochstreifen oder Lochkarten ab 
und erhielten die Ergebnisse in Ausdruck- 
en zurück. Die Programmierung erfolgte oft 
in Maschinensprache, wenngleich auch 
höhere Programmiersprachen wie Fortran 
durchaus verbreitet waren. Eine direkte 
Programmierung in Maschinensprache 
erlaubt dem Computer eine effiziente 
Abarbeitung eines Algorithmus, verlangt 
aber den Programmierer einiges ab. Die 
Prozessoren der Großrechner versuchten 
den Programmieren das Leben zu er- 
leichtern, indem sie komplexe Befehle für 
den jeweiligen Anwendungszweck wie 
Buchhaltung oder wissenschaftliche Be- 
rechungen boten. IBM beschritt mit seinem 
legendären System/360 schließlich einen 
neuen Weg und implementierte diese Be- 
fehle mittels Microcode. Das sind in einem 
CPU-eigenen Speicher abgelegte Rou- 
tinen, die hart verdrahtete Befehle der CPU 
verwenden und sozusagen die Firmware 
der CPU bilden. Dieser Komfort für den As- 
semblerprogrammierer wird mit einem 
Nachteil an anderer Stelle erkauft: Die Aus- 
führung der komplexen Befehle ist zeit- 
intensiv und nicht in einem CPU-Takt zu 
bewältigen. 


Die Anfänge 


Schon in den 1960er Jahren zeigte Sey- 
mour Cray, dass es auch anders geht. Cray 
war damals bei der Firma Control Data Cor- 
poration (CDC) angestellt. Mit den Erfah- 
rungen, die er bei der Entwicklung von 
Supercomputern bei seinem vorherigen Ar- 
beitgeber Engineering Research Asso- 
ciates (ERA) gesammelt hatte, stellte CDC 
im Jahr 1965 die CDC 6600 vor. Trotz 
durchschnittlicher Hardware besaß die Ma- 
schine eine herausragende Performance. 
Es handelte sich um eine 6-Bit 
Maschine mit Ringkernspei- 
chern und 18 Bit Adressraum. 
Das Besondere: Der Rechner 
kannte nur 64 Maschinenbe- 
fehle - genau so viele, wie in ein 
6 Bit Word passen. Komplexe 
Kommandos wie beim System 
/360 gab es nicht. Zwar mussten 
die Programmierer nun selbst 
implementieren, was der Rech- 
ner nicht konnte, dafür liefen die 
Programme deutlich schneller 
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Weniger ist mehr 


aspekt der Grund. Erst 1974 entwickelte 
John Cocke am Thomas J. Watson Re- 
search Center das RISC-Konzept für den 
Minicomputer IBM 801. In den 1970er-Jah- 
ren waren Hochsprachen schwer in Mode 
gekommen. Compiler übersetzten den für 
Menschen leichter verständlichen Quellco- 
de in Maschinencode. Cocke machte die 
Beobachtung, dass Compiler meist nur we- 
nige, elementare Befehle des Prozessors 
nutzten. Folgerichtig ersann er ein Design- 
konzept, bei dem der Prozessor nur dieje- 
nigen Maschinenbefehle kannte, die Com- 
piler vorrangig verwenden. Nicht mehr der 
CPU, sondern dem Compiler kam die Auf- 
gabe zu, komplexe Befehle in kompakten, 
vom Prozessor abzuarbeitenden Code zu 
übersetzen. John Cocke prägte auch den 
Begriff RISC für dieses Konzept und grenz- 
te es vom "Complex Instruction Set" oder 
kurz CISC des bisherigen Designs ab. 


Das Berkeley RISC Projekt 


Zwischen 1980 und 1984 führten Wis- 
senschaftler in Berkeley im Auftrag der De- 
fense Advanced Research Projects Agency 


orkstation Architecture 


u Andreas Bechtotsheim 


Der erste 
RISC Prozessor 


Auch an anderer Stelle exist- 
ierten Systeme und Prozessoren 
mit eingeschränktem Befehlssatz, 
beispielsweise die PDP-5 von 
DEC mit nur 3 Bit breiten Befehls- 
satz. Allerdings war hier mehr die 
Systemarchitektur an sich und 
weniger der Geschwindigkeits- 
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Die Vernetzung der Bibliotheksrechner in Stanford schuf 
das Stanford University Network SUN 


Bild: Peg Skorpinski (CC-BY-SA 3.0) 


David A. Patterson gilt als geistiger Vater 
des heutigen RISC-Designs 


(DARPA) das Forschungsprojekt Berkeley 
RISC durch. Unter der Leitung von David 
A. Patterson und Carlo H. Sequin sollte ei- 
ne Architektur für VLSI-Chips (Very Large 
Scale Integration) entwickelt werden. So 
entstanden zwei Chipdesigns, RISC | und 
RISC Il. 1981 erschien das Ergebnispapier 
mit dem Titel „Design and Implementation 
of RISC |“, das die Grundzüge der RISC 
Prozessoren beschreibt. Auf Basis dieses 
Dokuments begann sehr bald die Entwick- 
lung von RISC-Prozessoren für den kom- 
merziellen Gebrauch. Vor allem in Groß- 
britannien, wo 1983 Sophie Wilson mit der 
„Acorn Risc Machine“ (ARM) einen Prozes- 
sor für die Acorn-eigenen Microcomputer 
vorstellte. Auch die SPARC-Architektur von 
SUN hat ihre Wurzeln in diesem Projekt, 
ebenso der DEC Alpha Prozessor. David 
A. Patterson hat die RISC Entwicklung in 
den folgenden Jahrzehnten weiter voran- 
getrieben und ist heute zusammen mit Krs- 
te Asanovic der Entwickler RISC-V-Archi- 
tektur. 
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Was macht die RISC-Architektur nun so 
besonders? In klassischen RISC-CPUs er- 
folgt die Abarbeitung von Befehlen immer 
in vier Stufen: Ein Befehl wird aus dem 
Speicher geholt (Fetch), dekodiert (Deco- 
de), in die Ausführungseinheit des Prozes- 
sors geladen (Load) und dann ausgeführt 
(Execute). Bei dieser als Superskalarität 
bezeichneten Arbeitsweise befindet sich in 
jeder Stufe immer ein Befehl, die CPU ar- 
beitet diese Stufen wie am Fließband ab. 
Neben der Superskalarität zeichnet eine 
RISC-CPU auch eine große Anzahl frei be- 
nutzbarer Register aus. So erleichtert die 
CPU eine effiziente Codeoptimierung. Mehr 
dazu findet sich in den Artikeln zu HP PA- 
RISC ab Seite 25 und zu SUN SPARC ab 
Seite 28. 


Von der CPU zur Workstation 


Das kompakte Design der RISC-Prozes- 
soren und die damit verbundene geringe 
Stromaufnahme sowie die hohe Leistungs- 
fähigkeit rückte einen langgehegten Traum 
in greifbare Nähe. Forscher und Entwick- 
ler wollten vor dem Eindruck der ersten Mi- 
krocomputer von Apple oder Commodore 
nicht mehr auf Rechenzeit der Großrech- 
ner warten, sondern verlangten nach eige- 
nen Supercomputern auf dem Schreibtisch. 
RISC versprach die Möglichkeit, dies kos- 
tengünstig zu realisieren. Die damals be- 
reits mit CISC-Prozessoren (oft aus der 
Motorola 68000er Reihe) ausgestattete 
Klasse der Workstations schien die richti- 
ge Basis zu sein. Workstations sind Com- 
puter, die zur Benutzung durch einen An- 
wender gedacht sind. Ihre Domäne sind 
technische und wissenschaftliche Anwen- 
dungen. In lokalen Netzen miteinander ver- 
bunden und mit Mehrbenutzer-Betriebs- 
system ausgestattet, waren sie sehr attrak- 


Die CDC 6600 von Seymour Cray aus dem Jahr 1965 


Bild: https://commons.wikimedia.org, Public Domain 


Eine typische RISC-CPU 


tiv für Nutzer in Universitäten und For- 
schungseinrichtungen, aber auch in der 
Verwaltung oder der Medizin. Als erste 
Modelle sind hier sicher der Xerox Alto zu 
nennen, aber auch Apollo Domain und 
frühe Sun Systeme 

Workstations eroberten nicht nur neue 
Anwendungsgebiete, sie veränderten auch 
das soziale Gefüge im Computerbetrieb. 
Anders als in der Mainframe-Welt mit ihrer 
Trennung und Verteilung von Arbeitsabläu- 
fen auf verschiedene Rollen und Personen 
im Rechenzentrum hatte der Benutzer sein 
System fast unter alleiniger Kontrolle. Die 
Hierarchie beim Workstation-Betrieb kann- 
te oft nur die Trennung in Systemadminis- 
tratoren und Benutzer. Dies passte besser 
in die Stimmung des Umbruchs der 1970er- 
und 1980er-Jahre als der Mainframe-Be- 
trieb. Workstations wurden von unter- 
schiedlichen Herstellern produziert, nicht 
wenige davon angesiedelt im aufstreben- 
den Silicon Valley in Kalifornien. Systeme 
von Apollo Computer, DEC, Hewlett 
Packard, IBM, NeXT, Sun Microsystems 
oder Silicon Graphics teilten sich zwischen 
1980 und der Mitte der 2000er-Jahre den 
Markt. 


UNIX und GUI 


Das Betriebssystem der RISC-Worksta- 
tions ist fast immer ein UNIX-Derivat. Das 
kommt nicht von ungefähr, war doch die 
Universität Berkeley früh Unix System V- 
Lizenznehmer der Bell Labs (also AT&T). 
Die Universität hatte mit der Berkeley Sys- 
tems Distribution (BSD) seine eigene, er- 
weiterte Unix-Version im Angebot. Von BSD 
flossen viele Entwicklungen zurück in Sys- 
tem V. 

Ein weiteres Merkmal von RISC-Work- 
stations ist die besonders starke Grafikleis- 
tung. Auch ist eine grafische Benutzer- 
oberfläche fast immer vorhanden. Kein 
Wunder — Workstations eigneten sich bes- 
ser als Mainframes dazu, neue Bedienkon- 
zepte zu entwickeln und zu etablieren. 
Dieser technikhistorische Prozess des Ent- 
stehens und Optimierens von GUls wird er- 
lebbar beim Vergleich der Oberflächen des 
Xerox Alto, einer Apollo Domain Maschine 
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Die Apollo Domain DN4000 setzt auf einen 


Motorola 68030 Prozessor 


Bild: Lamune at English Wikipedia 


Eine SUN-3/80 Workstation 


Bild: CC-BY-SA 2.0 James O'Gorman 


Die SGI Iris Indigo, die erste Maschine 
gemäß der ACE Spezifikation 
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(also der CISC-Ära) mit den verschiedenen 
Ansätzen von SUN, DEC oder SGI bis hin 
zur Standardoberfläche CDE (common 
desktop environment). Genauso bezeich- 
nend für Workstations sind aber auch die 
innovative und herstellerspezifische Sys- 
tem- und Prozessorarchitektur und die 
Netzwerkfähigkeit mit TCP/IP. 

Die großen Hersteller wurden nicht mü- 
de, sich gegenseitig mit besseren und 
schnelleren CPUs übertrumpfen zu wollen 
Folgende sicher unvollständige Auswahl 
gibt hiervon einen Eindruck:. 


DEC fuhr zweigleisig: Einerseits 
brachte der Hersteller CISC-Ma- 
schinen mit den hauseigenen 32- 
Bit-VAX-Hauptprozessoren für das 
Betriebssystem VMS heraus, ande- 
rerseits erschienen MIPS-basierte 
RISC Workstations mit MIPS-CPUs 
und DEC Uiltrix (später OSF/1). 
SUN brachte die 32-Bit-SPARC 
und der 64-Bit UltraSPARC Linie auf 
den Markt. 
Hewlett Packard nutzte ab 1986 die 
32-Bit PA-RISC-CPUs (Precision 
Architecture), 1994 folgten 64-Bit 
Modelle. 
Silicon Graphics setzte auf die 
"Microprocessor without interlocked 
pipeline stages" (MIPS) Architektur 
der MIPS Computer Systems Inc. 
aus Stanford. 
IBM brachte mit den RS/6000 Ma- 
schinen leistungsfähige Worksta- 
tions mit PowerPC ("Performance 
optimization with enhanced RISC") 
Prozessoren heraus. 
Apollo Domain erlebte den Wandel 
von CISC zu RISC nicht mehr, in 
den Apollo-Workstations werkeln 
fast ausschließlich Motorola 68k- 
Prozessoren. 


Diese Entwicklungen ließen sich die Her- 
steller entsprechend bezahlen, RISC Work- 
stations waren niemals ein billiges Ver- 
gnügen. 


Client/Server vs. Mainframes 


Fließend ist die Grenze zwischen reinen 
Workstations zur Nutzung durch einen An- 
wender und dem Client-/Server-Compu- 
ting. Ursprünglich sollte jede Workstation 
in einem Netz ihre speziellen Funktionen 
allen anderen Maschinen anbieten können. 
So konnte ein Drucker, ein Scanner oder 
auch ein Modem alle Maschinen im Netz 
entsprechend versorgen. Entsprechend 
wurde auch die Software aufgebaut: Ein 
Serverprozess auf der einen Maschine 
bedient die angeschlossene Hardware, ein 
Clientprozess kommuniziert über das Netz 
mit diesem Server. Client-/Serverarchitek- 


turen erlauben auch andere Arten verteilter 
Software und eine Trennung von Anwen- 
dungen in eine Applikationsebene auf 
einem Server und einer Präsentations- 
ebene auf einem Client. Eine weitere 
Maschine mag bei Bedarf eine Datenbank 
als Backend bereitstellen. Dieses Design 
unterscheidet sich von monolithischen 
Anwendungen auf einem Mainframe, die 
über Terminals bedient werden. Die Her- 
steller platzierten diese Ansätze als Alter- 
native zu Mainframe-gestützten Anwen- 
dungen. Aber schnell war klar: Die zentra- 
len Teile dieser Softwarearchitektur brau- 
chen viel Power. Die Workstation-Hersteller 
brachten immer größere Systeme auf den 
Markt, abgeleitet aus der Architektur der ur- 
sprünglich kleinen Einzelplatzsysteme. 
Diese befriedigten den Leistungsbedarf von 
Datenbanken und Serveranwendungen 
und brachen in die Domäne der Mainframes 
ein. Mit Erfolg: Letztlich nahmen diese gro- 
ßen UNIX-Maschinen so schließlich die 
Rolle des Mainframe ein und verdrängten 
diese immer mehr. Heute bedienen Main- 
frames selbst meist Client-/Serversoftwa- 
re und punkten mit hoher Skalierbarkeit. 


Die Suche nach Standards 


Der Markt der Workstations war in den 
letzten beiden Jahrzehnten des letzten 
Jahrhunderts heiß umkämpft. Viele Her- 
steller und beinahe genauso viele Prozes- 
sor- und Speicherarchitekturen wetteiferten 
um die Gunst des Kunden. Die Konse- 
quenz: Um Interoperabilität der Systeme 
oder gar den Austausch von Software war 
es schlecht bestellt. Drittanbieter mussten 
ihre Produkte für eine Vielzahl von Plattfor- 
men anbieten, um den heterogenen Markt 
zu bedienen. Auch der Endanwender hat- 
te dadurch nicht immer nur Freude — wer 
die Beschaffung von Systemen hersteller- 
neutral ausschreiben musste, hatte über 
die Jahre bald einen Park der unterschied- 
lichsten Systeme im Hause. Großkunden 
wie Versicherungen entwickelten durchaus 
ihre eigene Middleware, um diese Samm- 
lung bändigen zu können. 

Das erkannten auch die großen Herstel- 
ler und so mangelte es nicht an Bemühun- 
gen, gemeinsame Standards zu etablieren. 
Die unterschiedlichen UNIX-Derivate wur- 
den dank System V und dem POSIX-Stan- 
dard miteinander kompatibel, zumindest in 
Bezug auf das Kompilieren des Quellcodes 
eines Programms. Auch das X Window 
System lieferte eine gemeinsam nutzbare 
Schnittstelle für grafische Anwendungen, 
die Motif-Bibliothek tat ihr übriges dafür. 
Der Anwender musste dank CDE beim 
Wechsel zwischen SUN-, HP- oder IBM- 
Maschinen nicht mehr umlernen, wenn es 
um die Nutzung der grafischen Oberfläche 
ging. 


Beispiel ACE 


Anfang der 1990er-Jahre trieb Compaq 
gemeinsam mit DEC und anderen die Grün- 
dung der Herstellervereinigung ACE (Ad- 
vanced Computing Environment) voran. 
ACE sollte einen Standard für MIPS Rx000- 
basierte Maschinen etablieren und stellte 
sich gegen SUN auf. Sowohl SUNSs eige- 
ne Maschinen als auch eine Reihe von 
SPARC-basierten Maschinen von Dritther- 
stellern hatten eine starke Marktpräsenz. 
ACE definierte eine modulare Architektur, 
gab mindestens MIPS R3000-Prozesso- 
ren, 8 MByte RAM, Ethernet, SCSI-II und 
viele weitere Leistungsmerkmale vor. Als 
Betriebssystem war das UNIX System V 
Release 3-Derivat Irix 4.0 vorgegeben, die 
GUI stützte sich auf X11R4, Display-Post- 
Script und OSF/Motif-Laufzeitbibliotheken. 
Die Referenzimplementierung von ACE ist 
wohl die SGI Indigo, eine Maschine in ei- 
nem kompakten Towergehäuse, in frechem 
Lila gehalten. Was sich mit der Indigo ma- 
chen lässt, zeigen Filme wie Terminator 2 
und Jurassic Park. Lange währte die Freu- 
de aber nicht. Zuerst zog sich Compaq zu- 
rück, bald darauf auch DEC, um einen 
Alleingang mit dem Alpha-Prozessor zu un- 
ternehmen. Während also der Architektur- 
standard ACE Schiffbruch erlitt, segelte 


Die Menschen dahinter 


Hinter den technischen Innovationen und den Produkten, 
die diese Innovationen zu den Nutzern tragen, stehen im- 
mer Menschen mit dem Antrieb, etwas Neues schaffen zu 
wollen. Wir stellen einige davon vor: 


John Cocke (Mai 1925 - Juli 2002) 
wechselte 1956 von der Duke Uni- 
versity als promovierter Mathe- 
‚matiker als Forscher zu IBM, wo er 
bis 1992 blieb. Seine Arbeiten zur 
Compileroptimierung sind essenti- 
ell für den Einsatz von RISC-Com- 
putern. 


Sophie Mary Wilson (geboren 

1957 in England) arbeitete nach 

ihrem Studium ab 1979 in der 

Firma Acorn, gegründet von ihrem 

früheren Lehrer Hermann Hauser. 

Zusammen mit Steve Furber ent- 

warf sie den ARM-32-Bit-RISC- 

Prozessor und seinen Befehlssatz. 

ARM-Prozessoren wurden in den Acorn-Computern 
Archimedes und RiscPC eingesetzt, Weiterentwicklungen 
treiben heute Smartphones und die Apple Macintosh M1 
Serien an. 


Andreas von Bechtolsheim (ge- 
boren September 1955) studierte 
zunächst an der TU München und 
wechselte dann als Stipendiat an 
die Carnegie Mellon University in 
Pittsburgh, USA. Anfang der 


SUN weiter mit gutem Wind voraus, dicht 
gefolgt von IBM und Apple, die mit dem 
PowerPC-Prozessor und der PReP-Platt- 
form ein ganz eigenes Boot zu Wasser lie- 
ßen. CPU-Hersteller MIPS wurde schlieR- 
lich von Silicon Graphics übernommen. SG 
selbst wurde 2R16 dann von Hewlett 
Packard geschluckt. 


Workstations heute 


Letztlich machte die Heterogenität in 
Hardware und Software zusammen mit der 
drastischen Leistungssteigerung der PC- 
Hardware und ihrem niedrigen Preis den 
klassischen Workstations schließlich den 
Garaus. Auch *BSD und Linux als frei ver- 
fügbare UNIX-Betriebssysteme taten ihren 
Teil dazu. Nicht von ungefähr verstehen wir 
heute unter Workstation einen gut ausge- 
statteten Windows- oder Linux-PC oder ei- 
nen fetten Apple Macintosh. Wer eine 
Maschine von SUN, SGl oder den anderen 
klassischen Herstellern erwirbt, sollte die- 
se Geschichte im Blick haben. Zwar ist nicht 
jede Hardware gleichermaßen geeignet, 
dem Retrocomputer-Fan Freude zu berei- 
ten, den meisten Spaß versprechen aber 
Systeme, die als Grafik-Workstations kon- 
zipiert sind. Hier sind die Parallelen in der 
Anwendung zu Windows-PCs oder Micro- 


1980er Jahre entwickelte er mit Unterstützung der DARPA 
auf Basis des Motorola 68000-Prozessors einen Arbeits- 
platzrechner für das Computernetzwerk der Universität. 
1982 gründete er die Firma Sun, um seine Entwicklung für 
den kommerziellen Markt herstellen zu können. Später 
wechselte er zum Netzwerkausstatter Cisco und schließ- 
lich zu Arista Networks. Seine Tätigkeit als Investor half 
unter anderem auch den Stanford-Studenten Larry Page 
und Sergei Brin bei der Gründung des Unternehmens 
Google. 


Bill Joy (geboren 8. November 
1954) studierte Elektrotechnik und 
Informatik an der Universität von 
Kalifornien in Berkeley und wirkte 
dort ab 1977 maßgeblich an der 
Berkeley Software Distribution 
(BSD) mit. Er trieb die Weiter- 
entwicklung von TCP/IP voran und 
gründete zusammen mit Vinod Khosla, Scott McNealy und 
Andy Bechtolsheim die Firma Sun Microsystems. Dort war 
er maßgeblich an der Entwicklung der SPARC- 
Prozessoren, aber auch an Solaris (SunOS), Java und Jini 
beteiligt. 


James Henry Clark (geboren März 
1944) gründete mit Absolventen 
der Stanford University die Firma 
Silicon Graphics, die Workstations 
mit sehr leistungsfähiger Grafik- 
hardware herstellte. 1993 gründete 
Clark zusammen mit Marc An- 
dreessen die Firma Netscape 
Communications Corporation. 


computern und Homecomputern am größ- 
ten. Insbesondere 3D-Bildverarbeitung, die 
Verarbeitung analoger Videosignale oder 
auch die Sound-Erzeugung sind Domänen 
der entsprechenden Maschinen. Auf den 
nächsten Seiten beleuchten wir die Her- 
steller solcher Workstations kurz und nen- 
nen besonders interessante Modelle und 
Technologien.(gb) 


Links 


https://www.bernd-leitenberger.de/ 
cisc-risc.shtml 
https://de.wikipedia.org/wiki/Seymour_Cray 
https://www.digisaurier.de/computerhelden-19- 
david-patterson-der-erfinder-von-risc-und-raid/ 
https://de.wikipedia.org/wiki/ 
SPARC-Architektur 
https://de.wikipedia.org/wiki/ 
Sun_Microsystems 
https://en.wikipedia.org/wiki/Sun_Enterprise 
https://de.wikipedia.org/wiki/PA-RISC 
https://de.wikipedia.org/wiki/ 
Virtual_Address_eXtension 
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John William Poduska Sr. (ge- 
boren 1937) studierte Elektrotech- 
nik am Massachusetts Institute of 
Technology. 1980 gründete er 
zusammen mit anderen die Firma 
Apollo Computer Inc. Dort 
entstand auch der RISC-Prozessor 
PRISM (Parallel Reduced Instruc- 
tion Set Multiprocessor) für die 
Apollo Domain DN10000 Worksta- 
tion. 
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Fast vergessen - Apollo Domain 


Apollo Computer Inc. wurde 1980 von William 
Poduska und anderen in Chelmsford (Massachu- 
setts) gegründet. Neben Symbolics und Sun Mi- 
crosystems war Apollo einer der Pioniere bei 
grafischen Workstations. Ein Jahr später kam die 
DN100-Workstation auf den Markt. Die Motorola 
68000-basierte Maschine läuft unter dem pro- 
prietären Betriebssystem Aegis. Die Modellpalette 
erweiterte sich nach oben mit zahlreichen Model- 
len mit Motorola 68030/50 MHz (9000/400DL) und 
68040/33 MHz (9000/4335). In Deutschland wur- 
den die Apollo Domain Maschinen von Siemens 
über der Bezeichnung WS vertrieben. Die Maschi- 
nen sind mit unterschiedlichen Grafikkarten aus- 
gestattet, je nach Modell für die Nutzung an 
monochromen ECL-Monitoren oder an RGB-Farb- 
bildschirmen. Massenspeicher sind bei älteren 
Modellen über ESDI angeschlossen, neuere ver- 
wenden SCSI. Das proprietäre Bussystem wich 
bald dem 16-Bit ISA-Bus (AT-Bus), für den es auch 
PC Emulatorkarten mit Intel 80386-Prozessor gibt. 
Zusammen mit der entsprechenden Software wird 
die Apollo Domain so MS-DOS-kompatibel. 

Aegis besitzt eine POSIX-kompatible Unix-Shell, 
ist aber eine Eigenentwicklung von Apollo. Sein 
Konzept basiert auf Multics, es ist jedoch in einer 
proprietären Version von Pascal geschrieben. 
Seine Stärke liegt in der Netzwerktransparenz: 
Kommandos können sowohl für die lokale 
Maschine als auch für entfernte Maschinen aus- 


geführt werden und Dateien (memory mapped files) 
können sich über das gesamte Netz erstrecken. 
Möglich ist dies durch einen eigenen, auf Token 
Ring aufbauenden Protokollstack. Erst später 
lernte Aegis mit dem darüber liegenden Domain/OS 
(Distributed On-line Multi-access Interactive Net- 
work/Operating System) auch Ethernet und 
TCP/IP. Domain/OS 10, enthält viele Elemente 
von Unix und kennt bereits das X Window System. 
Apollo Domain war sehr erfolgreich am Markt, 1987 
lag das Unternehmen beim Anteil am Workstation- 
Markt an dritter Stelle hinter Digital Equipment Cor- 
poration und Sun, aber vor Hewlett-Packard und 
IBM. Die Erfolgsstory endete um 1988 rasch in- 
folge von Fehlern und Börsenspekulationen des 
Managements. 1989 übernahm schließlich Hew- 
lett-Packard für 476 Mio. US-Dollar das Unterneh- 
men. Die Apollo-Maschinen wurden zunächst un- 
verändert neben den eigenen Workstations ver- 
kauft, bis 1997 war Apollo aber vollständig abge- 
wickelt. Workstations wie die HP Apollo 715 sind 
PA-RISC basiert und mit HP-UX als Betriebssys- 
tem ausgestattet. 


Stanford University Network wird Sun 


Als Ausgründung der Stanford University im Jahr 
1982 entwickelte sich SUN (eine Abkürzung für 
Stanford University Network) zum führenden Her- 
steller von UNIX-Workstations. Die Gründer An- 
dreas von Bechtolsheim, Bill Joy, Vinod Khosla und 
Scott McNealy verstanden sich darauf, den Bedarf 
an leistungsfähigen, vernetzten UNIX-Maschinen 
zu decken. Mit den Motorola 68010-basierten 
Maschinen SUN-1 und SUN-2 aus dem Jahr 1983 
brachte SUN gleich sein eigenes UNIX-Derivat 
heraus. SunOS 1.0 basiert auf 4.1BSD. 

Schon 1985 begann SUN damit, eigene RISC 
Prozessoren zu entwickeln, die SPARC-Architek- 
tur. Als 1986 die SUN-4 Systeme mit diesen 
Prozessoren vom Band liefen, fand sich SUnOS 
3.2 auf den Platten. Es zeigte bereits Einflüsse von 
System V und unterstützte die neuen Prozessoren 
nur teilweise. Schließlich wechselte SUN im Jahr 
1989 bei SunOS von BSD zunächst teilweise auf 
System V IPC. Diese Version unterstützt auch 
erstmals vollständig die 32-Bit SPARC-Architek- 
tur. 1989 ist auch das Gründungsjahr von SPARC 
International, einer Non-Profit Organisation zur 
Weiterentwicklung der SPARC Prozessoren. 
Hießen die Versionen bis 4.0 noch SunOS, führte 
SUN mit der Version 4.1.1 die Bezeichnung So- 
laris für seine UNIX-Variante ein. Ab Solaris 2.0 für 
SPARC war der Wechsel auf System V Release 4 
vollzogen. SUN nummeriert ab Solaris 2.0 übri- 
gens doppelt und übernimmt die Solaris-Version- 


snummer als Minor-Version für SunOS. Solaris 2.0 
ist SunOS 5.0, Solaris 7 entspricht SunOS 5.7 — 
etwas Verwirrung erhält ja die Aufmerksamkeit. 
1995 präsentierte SUN dann die ersten Maschinen 
mit dem UltraSPARC-Prozessor, bereits eine 64- 
Bit CPU. 

Die Modellpalette der UltraSPARC-basierten 
Systeme reichte bis weit in die Domänen herkömm- 
licher Mainframes. 1997 erschien die SUN Enter- 
prise 10000 (Starfire), die mit bis zu 64 Ultra 
SPARC Il-Prozessoren auf 16 CPU Boards be- 
stückt werden konnte. Die Maschine ist das Ergeb- 
nis der Arbeit der Business Systems Division von 
Cray Research. SUN hatte diese Abteilung über- 
nommen, nachdem Konkurrent Silicon Graphics 
1996 Cray Research geschluckt hatte, aber kein 
Interesse an der Business Systems Division zeigte. 
Die Starfire ist in Domänen aufteilbar und kann 
insgesamt mit bis zu 64 GB RAM bestückt werden. 
Um die Jahrtausendwende herum war diese 
Maschine bei Unternehmen des Internet-Hype sehr 
beliebt. Am günstigen Preis lag das nicht, für eine 
voll bestückte Starfire verlangte SUN etwa 1 Mil- 
lion US-Dollar. SUN nutzte den Markterfolg zur 
Übernahme verschiedener Firmen, unter anderem 
Tape-Roboterhersteller Storage Tek im Jahr 2006. 
Doch der Boom währte nicht ewig — 2009 wurde 
SUN schließlich selbst geschluckt. Datenbank- 
Spezialist Oracle ließ sich die Übernahme immer- 
hin 7,4 Milliarden US-Dollar kosten. 
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Pionier Hewlett Packard 


Hewlett Packard hatte zunächst UNIX-Work- 
stations auf Basis der Motorola 68000-Prozes- 
soren im Angebot, also CISC-basierte Maschi- 
nen. Die Serie 200 erschien erstmals 1931, 1985 
folgte die Serie HP 9000 / 300. Die von Apollo 
Computer übernommenen DN-Maschinen glie- 
derte HP als HP Apollo 9000 Serie 400 in das ei- 
gene Portfolio ein. Die Entwicklung der eigenen 
PA-RISC-Prozessoren lief parallel und 1986 
lieferte Hewlett Packard mit den Modellen 930 
(identisch mit HP 9000 840s) die ersten RISC- 
Workstations aus. Sie nutzen den PA-RISC-7000 
Prozessor mit 32-Bit Adressraum und einem 
großen, per Bussystem angebundenen L1- 
Cache, aber ohne L2-Cache. Die Prozessoren 
sind mit 35 bis 66 MHZ getaktet. 

Die Liste der PA-RISC basierten Systeme ist 
lang, aber durch die Trennung in verschiedene 
Serien noch halbwegs zu überblicken (siehe 
https://www.openpa.net/ systems/). Die HP 9000- 
Maschinen sind Workstations verschiedener 
Leistungsklassen. Die Anfang der 1990er Jahre 
vorgestellte HP 9000 715-Serie stellt kompakte 
Desktops mit PA-RISC-Prozessoren zwischen 
33 und 100 MHz und moderater Ausbaubarkeit 
hinsichtlich Speicher und Festplatten bereit. 
Ganz anders konzipiert ist der HP 9000 755 
Tower, hier passen bis zu 768 MB RAM und zwei 
5,25 Zoll SCSI-Platten in voller Bauhöhe hinein. 


Die HP Visualize Workstations kamen Mitte 
der 1990er Jahre auf den Markt und sind in die 
B-, C- und J-Serien zu unterscheiden. In allen 
Serien kommen PA-RISC Prozessoren unter- 
schiedlichem Entwicklungsgrad und unterschied- 
licher Taktfrequenz vor. Jüngster Spross dieser 
Linie ist wohl die C8000 aus dem Jahr 2004, die 
von zwei PA-8800 Prozessoren mit je zwei 
Kernen und einer Taktfrequenz von bis zu 1 GHz 
angetrieben wird. Daneben existieren mit den 
HP 9000 800-Maschinen auch Server mit unter- 
schiedlicher Ausstattung und Umbauten zu trag- 
baren Maschinen. 

Es lohnt sich vor dem Kauf einer HP-Worksta- 
tion daher genau zu schauen, in welche Serie 
die Maschine genau gehört und welche Be- 
triebssysteme sie fahren kann. Neben HP-UX 
als hauseigenem UNIX lassen sich auch Open- 
BSD und NetBSD, Linux und NeXT OpenStep 
installieren — nur eben nicht gleichermaßen auf 
jeder Maschine. Tückisch auch der Anschluss 
von Tastatur und Maus - ältere Modelle verwen- 
den hierfür das HP HIL-Bussystem oder einen 
Konnektor zum Anschluss von HIL- Komponen- 
ten und PS/2-Geräten. Auch hier muss der 
geneigte Sammler genau hinschauen, denn HP 
HIL-Geräte sind selten zu bekommen und ent- 
sprechend teuer. Adapter von HP HIL auf PS/2 
sind bisher nicht gesichtet worden. 


Silicon Graphics - der Grafikspezialist 


SGI begann mit den IRIS Modellen 1000 und 1200 
mit Motorola 68000-Prozessor im Jahr 1984. Die 
Maschinen waren als festplattenlose Grafiktermi- 
nals für Maschinen wie die DEC VAX gedacht. Erst 
spätere Serien einen eigenen Massenspeicher mit. 
Je nach Modell musste der Kunde zwischen 45.000 
und 100.000 US-Dollar für die Geräte locker machen, 
was trotz der geringen Zahl verkaufter Einheiten 
dem Unternehmen einen ansehnlichen Umsatz bes- 
cherte.1991 orientierte sich Silicon Graphics um und 
stellte mit der IRIS Crimson (ausgestattet mit einem 
64-Bit MIPS-R4000-Mikroprozessor) seine erste 
RISC-Workstation vor. Der Prozessor stammte von 
der 1984 gegründeten MIPS Computer Systems Inc, 
gegründet vom späteren Stanford-Präsidenten John 
L. Hennessy. SGl kaufte gleich danach den Prozes- 
sorhersteller auf, und benannte ihn ab 1992 iin MI- 
PS Technologies Inc. um. 

Danach folgten eine Reihe sehr erfolgreicher 
Grafik-Workstations. Die IRIS Indigo mit Prozes- 
soren der R4000-Serie machte als erstes Modell der 
ACE Referenzimplementierung Furore und gilt unter 
Sammlern oft als die schönste der SGI-Worksta- 
tions. Nachfolgemodelle waren die Indigo2- und In- 
dy-Workstations, letztere aus dem Jahr 1993 und in 
ein flaches Pizzabox-Gehäuse verpackt. Während 
die Indigo noch ein SGl-eigenes Bussystem für 
Tastatur und Maus besitzt, nutzen die Nachfolge- 
modelle die PS/2-Anschlüsse. Direkter Nachfolger 
der Indy ist die O2-Workstation aus dem Jahr 1996 


mit R5000- oder R10000-Prozessoren und maxim- 
al 256 MB RAM. Die Octane-Workstation kam 1997 
auf den Markt und ist mit zwei R10000 Prozessoren 
bestückt. Die 2002 erschienene Fuel fasst bereits 
maximal 1 GB RAM und ist mit Prozessoren bis hin- 
auf zur R16000 mit 900 MHz bestückt. Ähnliches 
gilt für den Octane-Nachfolger Tezro, nur vermag 
die Rack-Version dieser Maschine schon bis zu 16 
GByte RAM zu nutzen. 

Neben diesen Workstations für den Schreibtisch 
brachte SGI auch eine Reihe großer Server- 
maschinen auf den Markt. Unter den Onyx- und Ori- 
gin-Maschinen finden sich kühlschrankgroße Vari- 
anten der Workstations ebenso wie Rack-montierte 
Supercomputer für Grafikanwendungen. Aber SGl 
hat mit Kooperationen auch andere Märkte bedient. 
Die 1996 auf den Markt gekommene 64-Bit-Spiele- 
konsole Nintendo 64 enthält einen Grafikprozessor 
von MIPS Technologies. 

Von Haus aus verwenden SGI-Systeme das UNIX 
Derivat IRIX. IRIX 3.x basiert auf UNIX System V 
Release 3 und enthält Komponenten von 4.3BSD. 
Die 1993 erschienene Version 5.x hat Eigenschaften 
von UNIX System V Release 4 übernommen, unter 
anderem das ELF- Binärformat. In späteren Version- 
en fügte SGI das XFS Journaling Dateisystem hin- 
zu. Erst mit Version 6 unterstützte IRIX dann alle 
64-Bit-Features der MIPS Prozessoren. Letzte 
freigegebene Version ist IRIX 6.5 aus dem Jahr 
2006. 
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Big Blue mischt mit —- IBM RS/6000 


IBM hatte schon früh kleine Systeme für den Ein- 
zelanwender im Programm. In die Riege der An- 
bieter von RISC-Workstations stieg das Unter- 
nehmen 1986 mit dem IBM RT ein. Als Nachfolger 
des IBM 801 gehandelt, lieferte IBM sowohl eine 
Towerversion (Modell 6150) als auch eine Desktop- 
version aus (Modell 6151). Beide nutzen den 32- 
Bit-ROMP-Prozessor, an dem IBM seit 1977 ent- 
wickelte und der seit 1981 kommerziell verfügbar 
war. Er ist auf der Standard-Prozessorkarte des 
IBM RT mit 5,88 MHz getaktet, die Advanced Pro- 
cessor Card (ab 1987) taktet mit 10 MHz, die En- 
hanced Advanced Processor Card (ab 1988) mit 
12,5 MHz. Die Geräte nutzen IBM AIX als UNIX- 
Derivat, außerdem kann das Pick Operating Sys- 
tem und das Academic Operating System (AOS) 
als IBM-Port von 4.3BSD gefahren werden. 

Im Februar 1990 stellte IBM dann das RISC Sys- 
tem 6000 (kurz RS/6000) vor, angetrieben von der 
POWER1 CPU. Diese besitzt eine Multi-Chip-Ar- 
chitektur. Die RIOS-1 Konfiguration besteht aus 10 
einzelnen Chips, nämlich einem Instruction Cache 
Chip, je einem Festkomma. und einem FließR- 
komma-Chip, vier Data Cache Chips, einem Stor- 
age Control-Chip, zwei Ein- und Ausgabe-Chips 
und einem Clock Chip. 


Die parallel erschienene RIOS.9 CPU ist weit- 
gehend identisch, besitzt aber nur zwei Data 
Caches. 1992 erschien mit der RSC (RISC Single 
Chip) eine Version dieser Architektur auf einem 
einzigen Chip. Die Nachfolgeserie POWER2 baute 
diese Architektur durch je einen weiteren Fest- 
komma- und Fließkomma-Chip aus. RS/6000 
Systeme erschienen bis 1995 in verschiedenen 
Ausbaustufen. 

Als der PowerPC-Prozessor, ein gemeines Werk 
mit Apple und Motorola im Jahr 1992 erschien, 
wechselte IBM auch für die RS/6000-Maschinen 
auf diesen Prozessor. Der PowerPC setzt auf der 
RISC-CPU auf und hat über die Jahre viele Wei- 
terentwicklungen erfahren. Dementsprechend viel- 
fältig ist die Palette an PowerPC-basierten RS/ 
6000-Maschinen. Sie unterscheiden sich in der 
Auslegung als Workstation oder Server, im CPU 
Modell und der Anzahl von CPUs und dem maxi- 
malen Arbeitsspeicherausbau. Kam anfangs noch 
der MCA-Bus zum Einsatz, benutzten die 
späteren Modelle den PCI-Bus. 

Auch die RS/6000-Maschinen liefen mit IBM AIX 
als Betriebssystem. Daneben existieren Versi- 
onen von Microsoft Windows NT 3.51 und Sun Sol- 
aris, auch Novell Netware, OS/2 und Taligent war- 
en geplant. Aber nicht einmal das IBM-eigene OS/2 
ist in einer endgültigen Fassung für RS/6000 er- 
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schienen. 


Digital Equipment goes RISC 


DEC war im Workstation-Bereich spätestens seit 
1984 aktiv, als mit der Vaxstation | das erste 
schreibtischtaugliche Modell erschien. Angetrieben 
von einem KD32-CPU-Modul (4 MHz) mit dem Mi- 
croVAX-I-Prozessor war der Rechner die erste in 
VLSI Technik gebaute VAX (Virtual Address eX- 
tension). Dieser Prozessor ist ebenso wie seine 
Nachfolger eine CISC-CPU. DEC bot neben dem 
hauseigenen VMS mit Ultrix auch ein 4.2BSD- 
basiertes UNIX Betriebssystem an. Es unterstützt 
neben den Vax-Maschinen auch die DEC PDP-11. 

Ab 1989 sprang DEC auf den RISC-Zug auf und 
brachte die DECstation-Serie auf den Markt. Die 
Systeme nutzen die MIPS-Prozessoren der Sili- 
con Graphics Tochter MIPS Technologies, Inc. Die 
Modelle DECstation 3100 und 2000 nutzen den 
R2000 Prozessor und können mit Monochrom- und 
Farbgrafikkarten (8 Bit Farbtiefe) ausgestattet wer- 
den. Ethernet und SCSI runden die Systeme ab. 
Daneben bot DEC die Personal DECstation 5000 
Serie als Einstiegsmodelle an. Sie kamen mit MI- 
PS-R3000A oder R3010-CPU auf den Markt. Mit 
einem Preis von unter 1.000 US-Dollar für die klein- 
ste Ausstattung, zielten die Modelle auf den Markt, 
den Sun bis dahin besetzt hielt. In anderen Re- 
gionen bewegten sich die DECstation 5000 Mo- 
dell 100 und 200. Modell 100 ist mit R3000A- oder 
R4000-Prozessor bestückt zu finden, das Modell 
200 nutzt eine R3000-, R3400- oder R4400-CPU. 
Die Geräte schlucken verschiedene Farbgrafik- 
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karten sowie 2D- und 3D-Beschleuniger, immer 
angebunden über den DEC-eigenen Turbo Chan- 
nel. Mainboard, CPU-Modul, RAM, Netzteil und 
Grafikkarten nehmen soviel Platz im Desktop-Ge- 
häuse ein, dass Massenspeicher in ein eigenes 
Gehäuse ausgelagert werden müssen, die per SC- 
SI angebundene Expansion Box. Die Modell 200- 
Maschinen können beeindruckend viel Arbeits- 
speicher nutzen: Mit bis zu 15 SIMM-Modulen in 
DEC-eigener 128-Pin-Ausführung sind bei Ver- 
wendung von 32-MB-Modulen insgesamt 480 
MByte RAM möglich — nicht gerade wenig für eine 
Workstation von 1994. 

DEC glaubte indes nicht an eine große Zukunft 
der MIPS-Prozessoren. Stattdessen machte sich 
das Unternehmen daran, aufbauend auf den Kon- 
zepten von PRISM, einem Forschungsprojekt von 
DEC aus Mitte der 1980er Jahre, eine eigene CPU 
zu entwickeln, den DEC Alpha AXP. Ungebremst 
von Kompatibilitätsvorgaben setzte die CPU von 
Anfang an auf eine 64-Bit-Architektur. Mit Taktraten 
von anfangs 200 MHz (Modell 21064) im Erschein- 
ungsjahr 1992 bis zu 1,3 GHz im Jahr 2004 (Mod- 
ell 21364) hatte DEC wirklich schnelle CPUs im 
Portfolio. 1994 setzte DEC im Workstation-Bereich 
ganz auf den Alpha-Prozessor. Die DEC 3000 AXP- 
Modelle waren noch nahe an den MIPS-basierten 
Workstations, die DEC 4000 AXP zielten hingegen 
auf den Servermarkt. Noch größer sind die 
Maschinen der DEC 7000 AXP und DEC 10000 


NeXT Computer Inc. — Leistung ohne RISC 


NeXT Computer, Inc. war ein Unternehmen des 
Apple Gründers Steve Jobs und wurde gegrün- 
det, nachdem Jobs die Pionierfirma aus Cuper- 
tino verlassen hatte. Bei seiner Gründung 1986 
war der Öffentlichkeit noch unklar, was NeXT ei- 
gentlich produzieren und verkaufen wollte. Erst 
1988 wurde der Schleier gelüftet und Jobs stellte 
in einer typisch pathetischen Weise den NeXT 
Computer vor. Positioniert als Computer für die 
höhere Bildungsschicht, beeindruckte der schwar- 
ze Würfel mit einer Kantenlänge von 301 mm — 
also 1 Fuß nach klassischem Maß-- schon optisch, 
ebenso wie der Graustufenmonitor mit seinem U- 
förmig geschwungenen Ständer. Es handelte sich 
nicht um eine RISC-Workstation: Anders als Sun, 
aber vergleichbar mit Apollo Computer werkelte 
hinter der Hülle aus einer Magnesiumlegierung 
ein Motorola 68030, unterstützt von einem 68882- 
Coprozessor und einem 56001 digitalen Signal- 
prozessor (DSP). Diese Kombination erhöhte die 
Performance bei manchen Anwendungen deut- 
lich und glich die Schwächen des Hauptprozes- 
sors aus. Jobs verglich die Architektur des NeXT 
Computers in seiner Präsentation mit der klassis- 
cher Mainframes, was die Aufgabenteilung inner- 
halb der Maschine betrifft. 1990 brachte NeXT 
dann den leicht veränderten NeXTCube heraus, 


AXP Serien, sie sollten im Rechenzentrum 
gleichauf mit Mainframes rangieren. 

Mit Windows NT, DEC OSF/1 und Tru64 UNIX 
als Ultrix-Nachfolger sowie OpenVMS unterstützen 
gleich drei Betriebssysteme die DEC-eigene Ar- 
chitektur. Und weil ohne Anwendungen nichts 
geht, rühmte sich DEC zu dieser Zeit mit 2430 Pro- 
grammen, die unter OpenVMS laufen, 2506 unter 
DEC OSF/1 und 793 unter Windows NT. Nach un- 
ten hin rundeten die Alpha PCs der Handelsketten 
Vobis und Escom die Workstation-Palette ab, diese 
laufen unter Windows NT 4.0. Für Server und 
Workstations hingegen platzierte DEC dann doch 
lieber OSF/1 oder eben OpenVMS - je nach 
benötigter Anwendung. Der Alpha AXP-Prozessor 
mit 320 MHz wurde dennoch auf der CeBIT 1994 
als schnellster PC angepriesen. 

Dennoch genügten die Erfolge von DEC nicht, 
um ein langfristiges Überleben des Konzerns zu 
garantieren. Die Ausrichtung auf den Alpha AXP- 
Prozessor, ein eher nebenbei betriebenes Ge- 
schäft mit Intel-basierten PCs und Notebooks und 
das zunächst verschobene und schließlich ausge- 
fallene Release eines 64-Bit-Kernels von Windows 
2000 besiegelten das Ende des Unternehmens. 
1998 übernahm Compaq die Firma und mit der 
Übernahme eben dieser Compaq durch Hewlett 
Packard verschwand einer der Pioniere der Com- 
puterindustrie. 


der über einen 68040-Prozessor mit einem Takt 
von 25 MHz und einer Festplatte anstelle des im 
NeXT Computer verwendeten MO-Laufwerks ver- 
fügte. Für höhere Ansprüche in der Grafikdarstel- 
lung konnten die Würfel mit einer NeXTdimension 
genannten 32-Bit-Grafikkarte basierend auf dem 
Intel i1860-Prozessor aufgerüstet werden. Eben- 
falls 1990 lieferte NeXT die NeXTStation aus, 
ebenfalls mit einem 68040-Prozessor mit 25 oder 
33 MHz (NeXTStation Turbo) und wahlweise mit 
Farbgrafik (NeXTStation Color). 

Viel interessanter und bis in die heutige Zeit 
hineinwirkend sind das Betriebssystem, die Ent- 
wicklungsumgebung und die Programmierspra- 
che der NeXT-Maschinen. Eng verbunden mit dem 
NeXT-Computer ist die grafische Entwicklung- 
sumgebung Objects. Das ursprünglich NeXT Step 
genannte Betriebssystem setzt auf einem Mach 
Microkernel auf. Dieser verwaltet und abstrahiert 
die Hardware, alle weiteren Funktionen laufen als 
Prozesse dieses Kernels. Der Mach Kernel führt 
dann eine auf 4.3BSD-basierende UNIX-Umge- 
bung aus. Diese Architektur machte es später 
leicht, das Betriebssystem auch auf andere Ar- 
chitekturen zu portieren. Um 1993 konnte NeXT- 
Step so neben auf Motorola-CPUs auch auf Sun 
SPARC, HP PA-RISC und Intel 80486- Prozes- 
soren laufen. 


Von Anfang an setzte NeXT bei der Programmentwicklung neue Maßstäbe. Der 
Interface Builder erlaubt es, komplexe GUI-Anwendungen wie in einem Grafikpro- 
gramm zu designen und mit Programmcode zu hinterlegen. Als Programmiersprache 
wird dabei Objective C genutzt. Gemeinsam mit Sun definierte NeXT mit Openstep 
eine objektorientierte API und erleichterte so die Softwareentwicklung entscheidend. 
Programme wurden daher oft als NIHS-Versionen publiziert, taugten also für NeXT, 
Intel,- HP- und Sun-Maschinen gleichermaßen. 1993 gab NeXT schließlich die ei- 
gene Hardware auf und konzentrierte sich ab 1995 als NeXT Software, Inc. ganz 
auf API und Betriebssystem, nunmehr als OPENSTEP vermarktet. Als Steve Jobs 
im Dezember 1996 NeXT an Apple verkaufte und schließlich zu Apple zurückkehrte, 
wurde OPENSTEP und der Mach Kernel zur Basis von MacOS X. Auch die Ent- 


wicklungsumgebung und Objective C leben bei Apple in Xcode weiter. 


Homecomputer und Konsolen 


Wenn es um RISC-Prozessoren und machten ARM-Prozessoren mobil, wie 


RISC-Computer geht, darf eine Ar- 
chitektur nicht unerwähnt bleiben: ARM. 
Von den Acorn-Mitarbeitern Sophie 
Wilson und Steve Furber schon 1983 
begonnen, lieferten die ARM2-Prozes- 
soren in den Acorn Archimedes von 
1986 und später im Acorn RiscPC eine 
erstaunliche Leistung. Seit dem Jahr 
1990 als Advanced RISC Machines Ltd. 
ausgegründet, sind die Nachfolgemo- 
delle heute mehr denn je Vorreiter für 
leistungsfähige Computer und strom- 
sparenden Mobilgeräte. Smartphones 
und Tablets mit iOS und TabletOS von 
Apple oder solche mit Android von 
Google sind heute zahlenmäßig wohl 
die am meisten genutzten Geräte mit 
ARM-Prozessoren. Aber schon davor 


der Apple Newton einem der ersten Per- 
sonal Digital Assistents (PDA) zeigt. 

Auch MIPS-Prozessoren sind außer- 
halb von Workstations anzutreffen. Die 
Nintendo64-Konsole, die Sony Playsta- 
tion 1 und 2 und die Playstation Por- 
table nutzen MIPS-Prozessorkerne. Als 
hoch integriertes "System on a stick" 
finden sie sich beispielsweise ebenfalls 
in PDAs, aber auch in Netzkomponen- 
ten oder Network Attached Storage 
(NAS)-Systemen. 

Auch PowerPC-Prozessorkerne hat 
es auf Abwege verschlagen - sie treiben 
den Nintendo GameCube ebenso an 
wie die wenig erfolgreiche und selten 
anzutreffene Spielekonsole von Apple, 
den Pippin. 
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Leere Uhrenchips umschiffen 


Starthilfe 


Manche Workstation vergisst die 
eingestellte Uhrzeit nach dem Ausschalten 
und zeigt ein merkwürdiges Verhalten beim 
Hochfahren der Netzfunktionen. Vermutlich 
ist die Pufferbatterie leer — was nun? 


Die allermeisten Workstations speichern grundegende System- 
informationen in einem batteriegepufferten RAM (NVRAM, non 
volatile RAM) ab. Beliebt sind für diese Aufgabe die Uhrenchips 
der Hersteller SGS Thomson oder Dallas Semiconductor. So lie- 
gen Echtzeituhr und NVRAM zusammen mit einer Batterie in ei- 
nem kompakten DIL-Gehäuse vor. Das Problem dabei: Auch wenn 
diese Batterie nicht viel zu tun hat, nach zwei bis drei Jahrzehn- 
ten ist der Strom verbraucht. Anders als bei Mikrocomputern wie 
AMIGA oder Apple laufen die Batterien in den DIL Gehäusen nicht 
ohne weiteres aus, da sie zusammen mit dem Speicher- und Uh- 
renchip in Epoxydharz vergossen sind. Das ist die gute Nachricht, 
aber die schlechte folgt sogleich: Die Betriebssysteme der meis- 
ten Workstations erwarten essentielle Angaben im NVRAM. Fehlt 
der Batteriestrom, geht der Inhalt des NVRAM verloren und die 
Maschine funktioniert nicht mehr richtig. 

Es fehlt nicht an Anleitungen, wie mittels Teppichmesser oder 
Mini-Schleifmaschine ein Dallas-Chip so geöffnet werden kann, 
das die Batteriekontakte frei liegen und eine Knopfzelle als Ersatz 
eingebaut werden kann. Es bleibt aber die Aufgabe, das NVRAM 
dann neu zu programmieren. Wie das geht und welche Fehler ein 
leeres NVRAM verursacht, zeigen die nächsten Abschnitte. Wer 
den Aufwand des Batterieumbaus scheut, hat auch etwas von den 
folgenden Angaben. Nur sind dann diese Schritte bei jedem Boot 
der Workstation erneut erforderlich. 


Sun Solaris 


Sun Solaris fragt beim Systemstart unter anderem die System- 
ID und die MAC-Adresse des Ethernetanschlusses ab. Ohne ein 
entsprechend programmiertes NVRAM funktioniert der Autoboot 
der Workstation nicht. Auch eine Netzverbindung kommt nicht zu- 
stande, obwohl der Ethernetanschluss einen Link signalisiert. Der 
Befehl test net im OpenBoot zeigt einen Fehler an. 


a DALLAS 
DS12B887 


REAL TIME 
9818A2 101830 


Enthält eine Batterie — der Uhrenchip vieler Workstations 
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SUN NVRAM programmieren 

Solange der NVRAM-Chip nicht getauscht wurde, kennt sich die SUN sozusagen selbst 
nicht. Es fehlen aufrufbare Angaben für die Maschinen-ID und die MAC-Adresse. Diese 
lassen sich aber am Eingabeprompt des OpenBoot-PROM auch manuell setzen. Sie 
bleiben solange erhalten, wie die Maschine nicht ausgeschaltet wird. Die Kommandofolge 
zum Setzen der Bytes im NVRAM für eine Sun Ultra-1 ist etwas länger: 


set-defaults 
1 0 mkp 

80 1 mkp 

8 2 mkp 

0 3 mkp 

20 4 mkp 

xx 5 mkp 

yy 6 mkp 

zz a mkp) 

0 8 mkp 

0.9 mep 

0 a mkp 

0 b mkp 

xx c mkp 

yy d mkp 

zz e mkp 

0 £ 0 do i idprom@ xor loop f mkp 


Die mkp-Befehle setzen jeweils ein Byte des NVRAM. An Position 0 muss immer der 
Wert 1 stehen (1.0 mkp). Position 1 ist Byte 1 der Host-ID; hier ist das "80" für die Ultra- 
1. Die Positionen 2 bis 7 enthalten die MAC-Adresse. Hier sind die ersten drei Bytes die 
Hersteller-ID des Ethernet-Chips, bei SUN Ultra1 sind dies die Werte "80", "8" und "0". 
Die Positionen 8 bis 11 (hexadezimal also 0xB) sind das Release-Datum des Systems; 
das lässt sich gefahrlos auf "0" setzen. Die drei letzten Positionen sind Bytes 2,3 und 4 
der Host-ID. Diese muss identisch mit den drei letzten Bytes der MAC-Adresse sein. In 
der letzten Zeile folgt ein Forth-Befehl zur Erzeugung einer Prüfsumme über die einge- 
gebene Bytefolge. 

Nach Eingabe der Bytefolge startet der Befehl "reset" das System neu. Nun sollte neben 
dem Sun-Logo beim Boot die eingegebene MAC-Adresse stehen. Stimmt diese nicht, 
gab es einen Tippfehler in der Zeichenfolge. 


Eine genaue Beschreibung zur Programmierung des NVRAM 
zeigt der Kasten oben.. Wichtig zu wissen ist hier, dass jedes Sun- 
Modell eine passende Angabe braucht. Insbesondere die Maschi- 
nen-IDs weichen verständlicherweise zwischen den Modellen ent- 
sprechend ab. 


SGI Irix 


Eine SGI Indy startet ohne Angaben im NVRAM meist problem- 
los durch, hat aber Schwierigkeiten im Betrieb. IRIX zieht die IP- 
Adresse des Hosts nämlich aus dem NVRAM. Ohne diese Anga- 
be klappt die Netzkonfiguration nicht; spürbar wird das an langen 
Reaktionszeiten beim Anmelden und beim Aufruf von Program- 
men. 

Die manuelle Anpassung ist recht bequem: Beim Systemstart 
genügt der Aufruf des „Configuration mode“ und dort aus dem Me- 
nü der Wechsel in den „Command Monitor“. Mit dem Befehl 


setenv -f eaddr 08:00:69:nn:nn:nn 
lässt sich die MAC Adresse des Systems setzen. Dabei steht 
nn:nn:nn für die Seriennummer auf der Rückseite der Maschine. 
Die IP-Adresse wird dann mit dem Befehl 
setenv netaddr a.b.c.d 


gesetzt, zum Beispiel mit 


setenv netaddr 192.168.178.42. 


Netzkonfiguration bei Sun 


Netzhilfe 


Eine UNIX-Workstation macht erst dann richtig Spaß, wenn sie 
auch vernetzt ist. Die allermeisten Workstations besitzen schon 
von Haus aus mindestens einen Ethernetport, sei es als BNC-An- 
schluss, RJ45-Buchse oder AUI-Anschluss. Geräte, die nur über 
einen BNC-Anschluss für ein Koax-Kabel (Cheapernet) verfügen, 
sind zwar untereinander leicht zu verbinden. Da heute aber Vernet- 
zung mit Twisted Pair Kabeln und Switches die Regel ist, braucht 
eine Cheapernet-Verkabelung einen passenden Übergang. Glück- 
lich ist, wer einen großen Switch oder Hub mit einer BNC-Buchse 
besitzt. Aber auch kleine 2-Port Hubs mit BNC-Anschluss auf der 
einen und RJ45-Buchse auf der anderen Seite sind noch zu fin- 
den. Heute verfügen die allermeisten Switches über eine automa- 
tische Erkennung der Netzgeschwindigkeit (Autosensing), so dass 
sich der Nutzer keine Gedanken machen muss, ob sein Ethernet 
mit 10-, 100- oder 1000 MBit/s läuft. Bei Problemen lohnt es sich 
dennoch, entweder an der jeweiligen Workstation oder am Switch 
das Autosensing für den jeweiligen Port zu deaktivieren. Suchen 
beide Seiten gleichermaßen nach der richtigen Geschwindigkeit, 
kann mitunter überhaupt kein Ergebnis herauskommen. 

Etwas mehr Kopfzerbrechen bereitet hingegen die Netzkonfi- 
guration, denn hier gehen die unterschiedlichen UNIX-Derivate 
recht unterschiedliche Wege. 


Als Beispiel wollen wir eine neue Sun mit dem Namen mysunO1 
konfigurieren und ihr die IPv4-Adresse 192.168.178.42 geben. 
Das Netz hat die Netzmaske 255.255.255.0, der Router zum In- 
ternet hat die Adresse 192.168.178.1 und ist auch DNS-Server. 

Beginnen wir mit der Vergabe eines Namens für den Rechner. 
Er muss in der Datei /etce/nodename stehen, sie besteht also nur 
aus einem Eintrag: 


mysunOl 


Für die Vergabe der IP-Adresse der Netzinterfaces sind unter 
Solaris die Dateien /etc/hostname.interface zuständig, also bei- 
spielsweise /etc/hostname.hmeö für den Ethernetanschluss hmeO. 
Die Datei kann entweder den Rechnernamen oder eine IP-Ad- 
resse nebst Netzmaske enthalten. Gültige Einträge sind also 


192.168.178.42 netmask 255.255.255.0 
für die Angabe von IP-Adresse und Netzmaske oder 
mysunO0l 


für die Angabe eines Rechnernamens. In beiden Fällen muss 
/etc/hosts dem Namen eine Adresse zuordnen: 
mysun0l SPS A2 


In der Datei /etc/netmasks müssen außerdem die Netzmasken 
der angeschlossenen Netze stehen. Das ist in unserem Beispiel 
eine Zeile: 

192.168.178.0 2559255025540 


Unter Solaris 10 und neueren Versionen werden IP-Adressen 


in der Datei /etc/inet/ipnodes hinterlegt. Die erste Zeile setzt dabei 
IP-Adresse und Name für das Default-Interface, die weiteren für 
alle anderen Ethernetports. Manche Sun-Workstations verfügen 
über eine oder mehrere Quadport-Ethernetkarten und haben so 
eine größere Zahl an Interfaces. Ein Beispiel für /etc/inet/ipnodes 
mit drei Netzinterfaces: 


192 mysunOl 
192 ,2158,0.42 eril 
192, Ser eri2 


Damit wären die Interfaces konfiguriert. Nun kann es an die 
Routingkonfiguration gehen. In unserem Beispiel besteht sie aus 
der Angabe des Routers zum Internet, also des Defaultrouters. 
Das geschieht in der Datei /etc/defaultrouter. 


192, le 


Zu guter Letzt muss nun noch die DNS-Namensauflösung kon- 
figuriert werden. Hierzu dient wie bei vielen anderen UNIX Deri- 
vaten die Datei /etc/resolv.conf: 


nameserver 192.168.178.1 
nameserver 8.8.8.8 


Mit diesen beiden ersten Einträgen sind der Internetrouter als 
DNS-Server und ein weiterer Nameserver als Fallback definiert. 
Solaris nutzt nicht zwangsläufig DNS zur Namensauflösung, son- 
dern kann beispielsweise auch NIS (network information service) 
hierzu heranziehen. Diese Entscheidung wird in der Datei 
/etc/nsswitch getroffen. Solaris bringt vorkonfigurierte Bespiele 
dafür mit. Es reicht also, die richtige Beispieldatei zu kopieren: 


cp /etc/nsswitch.conf /etc/nsswitch.oldi 
cp /etc/nsswitch.dns /etc/nsswitch.conf 


Der erste cp-Befehl sichert eine möglicherweise vorhandene 
Datei; er wird also fehlschlagen, wenn keine /etc/nsswitch.conf 
vorhanden ist. 


www.pexels.com (Bild von www.fieldengineer.com) 


Iomega Laufwerke nutzen 


Anschluss- 
hilfe 


Ursprünglich als Floppydisk-Ersatz 
gedacht, eignen sich die ZIP-Laufwerke 
von lomega auch zum Datenaustausch an 
Workstations. 


Allerdings muss es schon ein Modell mit einer SCSI Schnittstelle 
sein — Parallelport-Laufwerke sind nicht geeignet und IDE- oder 
USB-Modelle finden an klassischen Workstations eine passende 
Schnittstelle. Was erforderlich ist, um ein angeschlossenes Laufwrk 
auch nutzen zu können, unterscheidet sich je nach Hersteller und 
Betriebssystem. 


Sun Solaris 


Exemplarisch sei im folgenden beschrieben, wie ein ZIP-Lauf- 
werk an einer Sun SparcStation 5 mit Solaris 7 einzurichten ist. 
Alles beginnt mit einer Definition in /etc/format.dat: 


elek msea = Wat N 


s elle = SEHEN 

ı ncyl = 2046 : acyl = 2 : pcyl = 2048 : nhead 
= al 

ı nsect = 40 : rpm : bpt = 20480 

partition = "Zip" \ 

3 elle = Izial 5 eellm = Ser \ 

az, Aal re, AS 


Hierbei beschreiben die einzelnen Parameter des ersten Blocks 
den Anschluss und die Größen des Laufwerks: 
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disk_type: Symbolischer Name des Laufwerks, hier "Zip" 
ctIr: Typ des Controllers, hier SCSI 

ncyl: Anzahl der erlaubten Datenzylinder auf dem 
Laufwerk, hier 2046 

acyl: Anzahl der Zylinder für Informationen wie der Liste 
defekter Zylinder, hier 2 

pcyl: Anzahl der physikalischen Zylinder, hier 2048 (ent- 
spricht ncyl + acyl) 

nhead: Anzahl der Schreib-/Leseköpfe, hier 2 

nsect: Anzahl der Datensektoren pro Track, hier 40 

rpm : bpt: Umdrehungen pro Minute für das Laufwerk, 
hier 20480 


Der zweite Block legt fest, wie Partitionen aufgebaut sind. 


partition: Ein symbolischer Name, hier "Zip" 

disk: Name des zugeordneten disk_type, muss dem oben 
vergebenen Namen entsprechen 

ctIr: wie oben 

<n> = x,y: Angabe von Beginn und Ende der Partitionen. 
Beim ZIP-Laufwerk wird immer Partition 2 benutzt und es 
sind zwei überlappende Angaben erforderlich, hier 2 = 0, 
192480 :2=0, 1159168 


Damit kennt Solaris 7 schon einmal das Laufwerk an sich. Nun 
müssen nacheinander die Befehle drvconfig und disks aufgerufen 
werden, um die Gerätedateien zu erzeugen. Den Rest erledigt das 
Dienstprogramm, das menügesteuert Plattenlaufwerke formatiert, 
partitioniert und benennt und fehlerhafte Sektoren verwaltet. Mit 
dem Aufruf format fragt die Workstation auf Plattenlaufwerke ab, 
liest ihre Bezeichnungen und zeigt eine Liste der Ergebnisse. Das 
ZIP-Laufwerk taucht hiermit der Angabe <drive type unknown> 
auf. In unserem Beispiel ist diesem Eintrag das Gerätedevice 
/dev/dsk/c0t5d0s0 zugeordnet. Je nach Ausstattung der Sun-Work- 
station kann die Bezeichnung abweichen. Im Dialog wird mit der 
Option "Label" diesem Gerät der Typ "ZIP" zugewiesen. Nun ist 
noch eine Partition anzulegen, dabei genügt es, die Vorgaben der 
entsprechenden Option zu übernehmen. Das Laufwerk ist nun 
partitioniert, es fehlt nur noch ein Dateisystem. Das erledigt der 
Befehl newfs: 


newfs /dev/dsk/c0t5d0s0 


Das dauert etwa 10 min, das ZIP-Laufwerk zeigt währenddessen 
kräftige Aktivitäten. Um es zu benutzen, braucht es nun nur noch 
in den Verzeichnisbaum eingehängt werden: 


mount -F ufs /dev/dsk/c0t5d0s0 /mnt 
Ein umount /mnt entfernt es dann wieder und mit 
eject /dev/dsk/c0t5d0s0 
wird das Laufwerk die eingelegte Disk aus. 
Das gleiche Prinzip gilt auch für Iomega JAZ Laufwerke, die im 
Gegensatz zu ZIP-Laufwerken echte Wechselplatten sind. Für die 


1 GByte- und 2 GByte-Modelle braucht es nur passende Einträge 
in die /etc/format.dat: 


disk_type="Jaz 1GB"\ 

Jecelr=SsesmN 
ıncyl=1018:acyl=2:pcy1l=1020:nhead=64\ 
ınsect=32:rpm=3600:bpt=16384 
partition="Jaz 1GB"\ 

dtek-UJaza ICEBNTeeIr=SesiEN 
:2=0,2084864 

disk type = "JAZ 2GB"\ 

3 Kiel = Seit N 


ı neyl = 952 : acyl = 2 : pceyl = 954 : nhead = 
6A :unsece = sarN 

: rpm = 5400 : bpt = 32768 

Posertıone EU AZB2GCBuN 

: disk="JAZ 2GB" : ctlr = SCSI \ 

20731899319 


Alles übrige funktioniert wie oben für die ZIP-Laufwerke be- 
schrieben. 


NexXT-Workstation mit NeXTSTEP 


lomega JAZ-Laufwerke funktionieren auch wunderbar zusam- 
men mit der schwarzen Hardware von NeXT Computers, Inc. Das 
Vorgehen ähnelt stark dem unter Solaris, was wenig verwundert, 
denn beide Betriebssysteme haben ihre Wurzeln in 4.3BSD. 

Hier braucht die Datei /private/etc/disktab einen passenden Ein- 
trag, im folgenden für ein 1 GB JAZ Laufwerk gezeigt: 


iomega jazjliomega jaz 1GBjiomega jaz 1GB 
G.60Jiomega jaz 1GB G.6002/1:\ 
:ty=removable_rw_sc- 
si:nc#1021:nt#64:ns#32:ss#512:rm#5394:\ 
:£p#320:bp#0 :ng#0:gs#0:ga#0:ao#0:\ 

:os=sdmach: z0#64:21#192:\ 
:pa#0:sa#2045952:ba#8192:fa#1024:ca#8:da#4096:r 
a#10:oa=time:\ 

:lia:ta=4.3BSD:aa: 


Nach einem Neustart des Rechners genügt es, ein Medium in 
das Laufwerk zu schieben. Das Betriebsystem meldet sich dann 
und schlägt vor, das Medium zu formatieren, entweder mit einem 
NeXT- oder einem Macintosh-Dateisystem. 


Anders als das Iomega ZIP Drive handelt es sich beim Jaz um ein 
Wechselplattenlaufwerk. Es wurde sowohl als Einzellaufwerk im 
kompakten Gehäuse angeboten als auch als Einbaumodell für 2,5" 
Schächte. Die Laufwerke und Medien sind als 1- oder 2 GByte 
Modelle verfügbar. 


Editor vi benutzen 


Tipphilfe 


Vi ist als Texteditor wohl auf jedem UNIX System zu finden. Die 
ursprüngliche Implementierung wurde von Bill Joy im Jahr 1976 
für eine frühe BSD-Version geschrieben und von POSIX 
standardisiert. Diese Version wurde niemals im Quelltext ver- 
öffentlicht, jedoch existieren eine Anzahl von Klonen mit zum Teil 
wesentlichen Erweiterungen. Viele verbindet mit dem vi eine 
Hassliebe, denn seine Unterscheidung Befehlsmodus, Einfüge- 
modus und Kommandozeilenmodus wirkt zunächst befremdlich. 
Dafür ist der Editor auf fast allen Systemen verfügbar, die Einsen 
und Nullen unterscheiden können und alle diese Reinkarnationen 
bedienen sich zumindest in den Grundzügen gleich. Darum gibt 
es hier eine kurze Liste mit den wichtigsten Funktionen. Zu allererst 
gilt es, sich den Wechsel zwischen den Modi einzuprägen. 


ESC 

Beendet den Einfügemodus und wechselt in den 
Befehlsmodus 

Doppelpunkt 

Wechselt aus dem Befehlsmodus in den 
Kommandozeilenmodus 


Danach ist alles ganz einfach. Im folgenden sind Funktionen im 


Kommandozeilenmodus mit einem vorangestellten Doppelpunkt 
gekennzeichnet, alle anderen sind Funktionen des Befehlsmodus. 


Eingabe hinter dem Cursor = 
Überschreiben R 


Zeile oberhalb einfügen oO 


Zeile in Puffer kopieren yy 


Bis Zeilenende löschen D 


Datei schreiben A 


vi verlassen ohne speichern :q! 


Zeilennummern anzeigen / nicht anzeigen :set number 
Von Dateianfang bis Dateiende Zeichen-folge :1,$ si@jrey/g 
ersetzen 

Zeilenanfang N 
Dateianfang 99 


Titelthema Workstations 


Commodore, Unix und viele Fehlentscheidungen 


UNIX für AMIGA 


Die Führung von Commodore setzte in den letzten Jahren 
ihres Bestehens verschiedene Unix-Versionen in den 
Sand. Unerschrockene Aktivisten konnten jedoch 
zumindest AMIX als UNIX für den AMIGA retten. 


ie Geschichte der Entwicklung 

der drei Unix-Versionen bei Com- 

modore ist verworren und weit- 
gehend unbekannt, obwohl sie durch 
Intrigen, Unfähigkeit und zwei Insolvenzen 
geprägt ist und so einen guten Stoff für ei- 
nen Thriller abgeben würde. In diesem Ar- 
tikel wage ich den Versuch, das Knäuel 
aufzudröseln und die einzelnen Handlungs- 
stränge zusammenzuführen. Zum Schluss 
gibt es dann doch noch einen versöhn- 
lichen Ausblick. 


Beginn der Unix-Aktivitäten — 
der C900 


1983 waren die Aktivitäten in Entwick- 
lung und Verkauf bei Commodore vom C64 
geprägt. Die PET-Serie („Personal Electro- 
nic Transactor“) für die Geschäftswelt er- 
hielt in diesem Jahr mit dem Commodore 
8296-D das letzte Familienmitglied und war 
technisch sichtlich ausgereizt. Auf der Su- 
che nach einem zukunftsfähigen Produkt 
nahm Lloyd Taylor, Vizepräsident für Pro- 
jektentwicklung, neben den PC-kompati- 
blen Computern auch das in Entwicklung 
und Wissenschaft bereits etablierte Unix- 
System in den Fokus (siehe das Buch von 
Brian Bagnall, „The Amiga Years“). Auch 
Commodore selbst hatte verschiedene 
Unix-Systeme im Einsatz, vor allem in der 
Buchhaltung und beim Design von Chips 
und Platinen. 

Wegen aktueller Rechtsstreitigkeiten 
nahm man aber nicht den neuen MC- 
68000er-Prozessor von Motorola in den 
Blick, sondern den Z8001 von Zilog. Die- 
sen durfte Commodore in der firmeneige- 
nen Chip-Schmiede MOS Technology 
sogar in Lizenz herstellen, was die Entwick- 
lung des neuen Rechners vereinfachte. Der 
intern „Z-Machine“ und später offiziell 


Beinahe eine UNIX-Workstation — 
Der AMIGA 3000T 


„C900“ getaufte Rechner sollte 256kB an 
Arbeitsspeicher (bis 2 MByte erweiterbar) 
und zwei Floppy-Laufwerke, jedoch keine 
Festplatte erhalten. Später wurde der mi- 
nimale Arbeitsspeicher auf 512 kByte fest- 
gelegt und eine 20 MByte-Festplatte in den 
Prototypen verbaut. Der Verkaufspreis war 
auf unter 2.000 US-Dollar anvisiert. Die In- 
genieure bei Commodore waren von die- 
sen Plänen aber nicht sehr angetan. Sie 
hätten lieber einen Business-Computer in 


einer Art weiterentwickeltem C64 gebaut. 
Zumindest hätten sie als Prozessor des 
C900 statt des Z8001 lieber den MC68000 
gewählt, weil dieser leistungsfähiger und 
bei den Softwareentwicklern weiter verbrei- 
tet war. Derartige technische Fragen wur- 
den aber damals eben vom Management 
selbst entschieden. 

1984 verließen einige der wichtigsten am 
C900 arbeitenden Entwickler Commodore 
vor allem in Richtung Atari. Dies warf das 
ganze Projekt zurück. 


Software für den C900 


In den 80er-Jahren gab es nicht das „ei- 
ne“ UNIX, sondern verschiedene Firmen 
brachten jeweils ihr eigenes UNIX auf den 
Markt. Dabei durfte man den Quellcode des 
ursprünglichen AT&T Unix ab den frühen 
1980er Jahren nicht mehr verwenden, son- 
dern musste völlig eigenständige Fassun- 
gen der Software entwickeln. Commodore 
hatte damals keine Entwickler mit Unix- 
Kenntnissen, so dass man auf das bereits 
veraltete Coherent OS zurückgriff, das ne- 
ben anderen Einschränkungen keinerlei 
Netzwerkfähigkeiten hatte. Coherent OS 
war ein sogenanntes „Version 7 Unix“, das 
auf dem technischen Stand von 1979 war. 
Da bei Coherent ebenfalls viele wichtige 
Entwickler die Firma verlassen hatten wur- 
de kaum mehr an der Software weiterge- 
arbeitet. Eine Firma, der gerade die 
wichtigsten Hardware-Entwickler wegge- 
laufen waren nutzte also ein veraltetes Be- 
triebssystem einer Firma, der die wichtig- 
sten Software-Entwickler weggelaufen 
waren. 

Auch bei der Entwicklung einer grafi- 
schen Benutzeroberfläche lief nicht alles 
rund. Erst durch die Unterstützung exter- 
ner Entwickler konnten erste erfolgreiche 
Versuche zur Nutzung von Grafik unter- 
nommen werden. Wie auch bei Unix selbst 
waren auch die Benutzeroberflächen zu 
dieser Zeit individuelle Einzellösungen. Das 
später als Quasi-Standard weit verbreitete 
X Window System („X11“) kam erst im Sep- 
tember 1987 auf den Markt, also zu einer 
Zeit, als das C900-Projekt schon fast fünf 
Jahre alt war — und bereits zwei Jahre tot. 


Die erste Commodore Unix- 
Workstation steht kurz vor 
dem Verkauf 


Im April 1985 sollte der Prototyp des 
C900 erstmals auf der Hannover-Messe 
vorgestellt werden, zusammen mit dem 
C128. Das Gehäuse ähnelte dem des spä- 
teren Amiga 2000, war aber etwas größer. 
Der Amiga 1000, obwohl ebenfalls weitge- 
hend fertig, wurde dort erstaunlicherweise 
nicht gezeigt. Das Betriebssystem des 
C900 lief und rief zusammen mit der hoch- 
auflösenden Grafikoberfläche intern schon 
vorab Begeisterung hervor. Auch die Kon- 
kurrenz war beeindruckt. Commodore- 
Chefentwickler Bob Welland berichtete, 
dass mehrere Vertreter von SUN Microsys- 
tems lange staunend vor dem Rechner ge- 
standen hätten. Kein Wunder, der Rechner 
konnte neben einer beeindruckenden Gra- 
fik auch mit Timesharing, Multitasking, ei- 
ner funktionierenden Memory Management 
Unit (MMU), virtuellem Speicher und — über 
zwei bzw. vier RS232-Schnittstellen zum 
Anschluss von Terminals — auch mit einer 
Multi-User-Fähigkeit aufwarten. Neben den 
Fähigkeiten einer Grafik-Workstation war 
der C900 also auch als Mainframe mit bis 
zu fünf gleichzeitig arbeitenden Nutzern 
einsetzbar. 

Es wurden in der zweiten Jahreshälfte 
1985 etwa 400 Exemplare des C900 in zwei 
Konfigurationen mit unterschiedlicher mo- 
nochromer Auflösung gebaut und an Soft- 
wareentwickler und Computermagazine 
geschickt. Schon am 3. Dezember wurde 
dann aber in der Zentrale von Commodo- 
re das Ende des C900 beschlossen. Im 
Ressourcen- und Aufmerksamkeits-Drei- 
kampf mit dem Amiga und den PC-Nach- 
bauten zog der C900 zum Schluss den 
Kürzeren. Nach dem Einstampfen der Serie 
mussten die verliehenen Computer zur Ver- 
nichtung zurückgeschickt werden. Andere 
Quellen sprechen davon, es habe sowie- 
so nur 50 gebaute C900 gegeben, und die- 
se seien 1986 für 2.500-4.000 US-$ pro 
Stück verkauft worden. Jedenfalls haben 
nur wenige Exemplare überlebt. 


Parallele Unix-Aktivitäten bei 
den PC-Kompatiblen 


Schon früh in der Entwicklung des C900 
hatte sich herausgestellt, dass das Mana- 
gement bei Commodore Unix eine große 
Zukunft vorhersagte -- nicht nur in der Buch- 
haltung, sondern in Banken und Firmen ins- 
gesamt. Der Stern des Z8001-Rechners 
sank trotzdem immer schneller, aber ein ei- 
gener Unix-Rechner sollte unbedingt auf 
den Markt kommen. Da passte es gut ins 
Bild, dass Commodore seit Anfang der 
80er-Jahre eigene PC-kompatible Syste- 
me auf den Markt gebracht hatte. In etwa 


Mein Amiga 3000T 


1994 war ich in der Schweiz mit meiner Diplomarbeit 
beschäftigt, als mich der Anruf eines Freundes erreichte: 
Ob ich ihm bitte aus der Nähe von Zürich einen Computer, 
den er gerade dort gekauft hatte, mitbringen könne? Es 
handle sich um einen Amiga 3000T. Zu dieser Zeit hatte 
ich immer noch meinen Amiga 1000, den ich im Juni 1986 
erworben hatte, als Arbeitsrechner. Ich hatte ihn zwar um 
2MB Hauptspeicher, eine 45MB SCSI-Festplatte am Pa- 
rallel-Port und um eine Uhr erweitert, die Geschwindigkeit 
war aber dieselbe geblieben. Zu dieser Zeit überlegte ich, 
den Rechner mit einer Turbokarte, mehr Speicher, einer 
größeren Festplatte sowie Kickstart auf ROM statt von 
Diskette aufzurüsten. Die zu erwartenden Kosten von fast 
3.000 DM hielten mich davon ab, hier tätig zu werden. 
Gerade der Einsatz von LaTeX und der notwendigen Ge- 
nerierung von Zeichensatzdateien, die Wochen an 
Rechenzeit benötigten, ließen mich aber auf eine schnelle 
Lösung hoffen. 

Beim ersten Blick auf den neuen Rechner beim Auspack- 
en ließ mich den schnellen Entschluss fassen, den 
gleichen Computer kaufen zu wollen. Alleine die Möglich- 
keit fehlte: Angeblich war der Züricher 3000T der letzte 
3000er Amiga, der in Europa neu verkauft wurde. Und tat- 
sächlich, nirgends mehr war noch ein Amiga 3000 zu 
bekommen, weder als Desktop noch als Tower. 

Zur Computer Messe "94 in Köln hatte ich dank Presse- 
ausweis eine Stunde früher Zutritt. Das kam mir sehr zu- 
pass, denn einer der Händler hatte den Amiga 3000T neu 
für 2.500 DM angeboten, also 75% unter dem Listenpre- 
is von 10.000 DM. Leider erfuhr ich vor Ort, dass er von 
seinem Großhändler kein einziges Exemplar geliefert 
bekommen hatte. Bei einem zweiten Händler erfuhr ich 
hingegen, wo noch sechs neue Amiga 3000T stehen 
würden - nämlich im Büro des Konkursverwalters, der aus 
im Lager herumliegenden Einzelteilen noch insgesamt 


gleichzeitig mit dem Amiga 3000 UX und 
dem C900 präsentierte Commodore des- 
halb in Partnerschaft mit Garmhausen & 
Partner noch eine weitere Familie von Unix- 
Maschinen auf Basis der „Commodore Pro- 
fi Line“. Dabei gab es jeweils zwei Work- 
stations (WSX | und WSX Il) sowie zwei 
Server (UXS I und UXS Il). 


UXSII... 


Wer schon den C900 für einen unbe- 
kannten Computer hält, der sieht sich auf 
der Suche nach Informationen zur Com- 
modore Profi Line noch weit größeren Her- 
ausforderungen gegenüber. Zum Server 
UXS II sind wenigstens noch die Rahmen- 
daten zu finden: Als Basis wurde mit dem 
TW 486-25C mit einer 380 MByte SCSI- 
Festplatte, einem Streamer, zwei Disket- 
tenlaufwerken, 16 MByte Haupt- und 32 
kByte Cache- Speicher sowie sage und 
schreibe 16 serielle Schnittstellen auf einer 
einzigen Karte eine leistungsfähige Grund- 
lage geschaffen. Als Betriebssystem kam 
SCO-UNIX System V Release 3.2 zum Ein- 
satz, laut Magazin "Comm" das „meist in- 
stallierte UNIX-Betriebssystem auf Rech- 
nern mit 80386- und 80486-Prozessoren“. 
Gedacht war der Rechner als „Abteilungs- 


sechs Rechner zusammenbauen ließ. Dieser zweite 
Händler wollte tatsächlich den vollen Listenpreis dafür 
haben. Ich kam aber auf eine andere Idee. Ich brachte 
den ersten Händler und den Konkursverwalter unter der 
Bedingung zusammen, dass ich einen der sechs Rechner 
für den beworbenen Preis von 2.500 DM kaufen könne. 
Der Händler sah bei diesem Preis seine Felle davon 
schwimmen, aber ich konnte ihn überzeugen, dass fünf 
mal eine gute Marge besser wäre als gar nichts. Der 
Händler hielt sein Wort, und zwei Wochen später brachte 
mir die Post die Kartons mit dem Rechner und dem Zube- 
hör. 

Eine Seriennummer hatte er keine, die Anleitung von 
Scala war in Italienisch und die Tastatur auf Französisch, 
aber das konnte ich zum Glück in deutsche Versionen 
tauschen. Dazu dann noch 16MB Hauptspeicher, ein CD- 
ROM-Laufwerk, eine Picasso Il-Grafikkarte, ein A3070 
Streamer und ein hochwertiger Idek liyama 17-Zoll-Mo- 
nitor nachgerüstet, Meine persönliche Workstation war 
fertig! Mit NetBSD 0.9, Amiga DOS 3.1 und Macintosh 
System 7.5 fühlte ich mich gut für die Laborarbeit gerüstet. 
Ich brachte den Rechner mit in die Firma, bei der ich 
meine Diplomarbeit anfertigte. Die Kollegen konnten sich 
vor Lachen nicht mehr halten, brachte „der Deutsche“ 
doch einen vermeintlichen Spielcomputer ins Labor! Als 
ich den Rechner aufgebaut hatte und vorführen konnte 
verschlug es ihnen angesichts ihres eigenen Macintosh Il 
mit einer Auflösung von 640x480 ersteinmal die Sprache. 
Ich konnte tatsächlich mit dem Amiga Textverarbeitung 
machen und gleichzeitig mit Hilfe der Software „Shape- 
shifter" auf dem gleichen Computer unter dem Macintosh 
System mit Excel arbeiten. Mit MS-DOS, dem dfritten 
gleichzeitig laufenden System konnte ich unsere Mess- 
geräte kalibrieren oder auslesen. 


rechner, Datenbank- und Bürokommunika- 
tionsserver“ ("Comm"). Vertrieben wurde 
der Rechner nur von solchen Commodo- 
re-Fachhändlern, die Unix-Kompetenz hat- 
ten — oder dies zumindest der Zentrale 
gegenüber glaubhaft machen konnten. 

Schon eine Ausgabe vorher hatte das 
Magazin „Comm“ über den Einsatz des 
WSX Il bei der Steuerung von LKW-Flot- 
ten aus dem All berichtet, damals allerdings 
mit etwas anderen Rahmendaten. So soll- 
te der WSX II nun auf dem Desktop-Rech- 
ner DT 486-25C beruhen und über 64 kByte 
Cache-Speicher, dafür aber nur 8 MByte 
Hauptspeicher und eine 200MB Festplatte 
verfügen. Immerhin setzte die Commodo- 
re Büromaschinen GmbH in Frankfurt im 
Dezember 1991 selbst einen WSX Il als 
UUCP-Server für zwei Telefonanschlüsse 
ein. 


„.und WSX I, WSX Il, UXS I 


Zum WSX I und den beiden UXS I und 
UXS II finden sich hingegen in den Weiten 
des Internets keine weiteren Daten. Selbst 
in den Prospekten der Profi Line wird der 
TW 486-25C-Rechner selbst zwar genannt, 
allerdings nur mit MS-DOS als Betriebssys- 
tem. Unix wird hier an keiner Stelle erwähnt. 
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RUNNING COMMENTARY ON 3000UX PERFORMANCE 


f you really want to know 
how the Amiga 3000UX. 
brings UNIX System V 
Release 4 10 the worksta- 
tion, you should ask the people who 
use it. So we did. Listen to what 
Amiga 3000UX users at some of the 
nation’s leading institutions, und a 
leading publication, have 10 say. 


"The für 
aThe Badge jet fr ouperiermed 


Last year, aller years of using 
Apple Macintosh” systems. Virginia 
Tech’s Computer Science Depart- 
ment decided to change suppliers for 
their student computers, The school’s 
computer science majors are required 
to buy UNIX-based systems, and 
from now on, the Department says, 
they'll be buying Amigas. 


The decision was not a hasıy 
one. The department carried out an 
exhaustive review 
of systems from all 
of Ihe major UNIX 
players — nearly 
20 in all — before 
making a choice. 
And the winner was 
the Amiga 
3000UX. Why? Ask James Arthur, 
Associate Professor ol Computer 
Sciences at Virginia Tech and 
Chairman of the department's PC 
selection committee. 


The Amiga 3000UX, Arthur 
says, “was head and shoulders above 
Ihe other machines. The Amiga just 
far outperformed Ihe others. We 
coukd have been conservative and 
gone with the IBM“ or the Epson®, or 
we could go out on a limb and get a 
Iot more machine for the money.” 
“Ne hırve been using Amiga almost 
from day one.” 

At Westinghouse Science and 
Technology Center's IIuman 
Seiences Department in Pittsburgh, 


the Amiga is an indispensable part of 
the company’s advanced research 
efforts. Lab Manager Gary Sherwin 
is crystal-clear about Ihe reasons. 


“We have been using the Amiga 
for advanced scientific research 
almost from day one.” says Sherwin. 
“Tlike ıbe solidity of UNIX and the 
usefulness of being able to run multi- 
ple operating systems on Ihe same 
machine,” 


“The most complete implementation 
of UNIX SVRA.” 

You may have seen Ben 
Smith’s review ofthe Amiga 
3000UX in the December, 1990 issue 
of Byte magazine. In his article, titled 
“A UNIX Graphics Workstation for 
the Rest of the World,” Smith had 
Ihis 10 say about the Amiga 3000UX: 


“This workstation is the most 


complete Implementation of the new 
AT&T UNIX System V Relcasc 4. 
[11] is not a clone, nor a work-alike, 
nor a toy. It is a no-nonsense work- 
station that is impressive and com- 

he Amiga 3000UX greatly 

rms the equivalent NeXT* 

intosh with A/UX*,.. it is um 

obvious choice as a low-end worksta- 
tion.” 


“As slidk an implementation as any 
I've seen.” 

At the University of Southern 
California, Amiga 3000UXs arc up 
and running after being connected 
with the school’s existing network. 
How does USC Director of Systems 
Mark Brown rate Ihe Amiga’s con- 
nectivity? Listen: 


“It is] as slick 
an implementation 
as any T’'ve seen,” 
Brown says. "We 
took it out of the 
box, switched iton 
and connected it to 
our network. lt 
worked fine.” 


“Amiga UNIX is an 


System V Release 4.” 
Richard A. 
Mincr, Rescarch 
Manager at the 
University of 
Lowell’s Center for 
Productivity Enhancement. makes 
Ihese observations about Ihe Amiga 
3000UX as a research tool: 


“]lere at Lowell, we run an 
industry-conscious center where we 
conduet rescarch and development of 
hardware and software for Fortune 
500 companies. We have been work- 
ing with Ihc Amiga UNIX System 
since the early prototype stage, and 
have produced a number of signifi- 
cant applications and development 
tools. The robust implementation of 
the operating system and environ- 
ment, along with the availability of 
standards in Amiga UNIX, have 
enabled us to integratc with our other 
systems and port numerous 
applications. Amiga 
UNIX is an impres- 
sive implc- 


mentation 
of System V/ 
Release 4.” 


Commodore preist in dieser Broschüre vollmundig sein UNIX für AMIGA an 


Andere Unixen 


Ich arbeitete etwa bis Ende des Jahrtau- 
sends mit meinem Amiga und NetBSD, bis 
ich dann auf einen PC-Kompatiblen Rech- 
ner mit K6-Il-Prozessor und Linux im Big 
Tower umstieg. AMIX war mir damals nur 
prinzipiell bekannt. 

Im Rechenzentrum der Universität Karls- 
ruhe gab es im Keller einige Tische, auf de- 
nen immer wieder Computer und Zubehör 
standen, die „zum Mitnehmen“ waren. So 
kam ich Anfang des Jahrtausends an eini- 
ge Unix-Workstations und Server mit un- 
terschiedlichen Unix-Versionen: von SUN 
so ziemlich alles von der SUN 3/60 über 
zwei Sparcstation 1 bis zur Ultra 10, von 
HP eine 9000/715, eine 9000/735 und ei- 
ne 8000/825, dazu von DEC eine Vax, ei- 
ne DECstation und eine Alpha. Ein guter 
Freund schenkte mir seine NeXTstation, ei- 
ne SUN Javastation erwarb ich bei einer 
Online-Auktion. Sprich: Es hatte sich ein 
ganzer Zoo angesammelt, aber ausgerech- 
net AMIX fehlte. 


AMIX, eine Beschreibung 


Anfang 1988 verriet der CEO von Com- 
mocdore, Irving Gould, der Presse die Plä- 
ne zum A2500UX, was die Entwickler unter 


Druck setzte (siehe Brian Bagnall, „The Fi- 
nal Years“). Vorher gab es nur eine Mach- 
barkeitsstudie, die erst ab diesem Zeitpunkt 
auf Amiga-Hardware lief, nämlich auf der 
neuen A2620-Beschleunigerkarte. Diese 
enthielt einen MC68020-Prozessor und ei- 
ne MC 68851 Memory Management Unit 
(MMU). Als Listenpreis waren für den Rech- 
ner 4.699 $ geplant, dazu kamen die Kos- 
ten für AMIX selbst. Eine der ersten 
öffentlichen Vorführung von AMIX erfolgte 
im gleichen Jahr auf der Uniforum Confe- 
rence in Dallas. 

Auf der Business Computing Show 1991 
wurde das System in fast fertigem Zustand 
vorgeführt. Als Hardware verwendet wur- 
de dabei ein Prototyp eines Amiga 3500, 
der ein Towergehäuse des PC-kompatiblen 
Rechners PC60-Ill mit einem neuen Main- 
board des Amiga 3000 mit mehr Slots ver- 
band. Der Amiga 3500 wurde 1991 als 
Amiga 3000T (im Towergehäuse) auf den 
Markt gebracht, erhielt aber eine andere 
Front, die sich optisch mehr an das 
Desktopgehäuse des A3000 anlehnte. Der 
A3000UX - ein Amiga 3000 mit AMIX, dem 
AS307- Streamer, einer 2410-TIGA-Grafik- 
karte, der A2065-Ethernetkarte, und einer 
Maus mit drei Tasten — wurde dann für 
6.998 US-$ angeboten, aber nur in sehr 
kleinen Stückzahlen verkauft. Schon am 


25. Juni des gleichen Jahres stoppte Meh- 
di Ali, der Präsident von Commodore, das 
„Projekt Unix“. 

Eines der Probleme war, dass AMIX aus- 
schließlich mit der MC68851-MMU zusam- 
menarbeitete. Diese war aber nur für den 
MC68020- und den MC68030-Prozessor 
verfügbar. Schnellere Prozessoren wie der 
MC68040 waren also nicht kompatibel, und 
eine Anpassung von AMIX hätte viel Zeit 
und Ressourcen gebraucht. Doch die stand 
Commodore zu diesem Zeitpunkt nicht 
mehr zur Verfügung, denn es hatte einfach 
zu lange gedauert, das System auf den 
Markt zu bringen. Ein oder zwei Jahre frü- 
her wäre der geforderte Preis noch konkur- 
renzfähig gewesen. 


Endlich: Auftritt AMIX, erster 
Akt 


Ich machte mich deshalb auf die Suche 
nach den AMIX-Installationsmedien. An 
das Original-Streamertape zu kommen war 
schon damals aussichtslos. Aber immerhin 
wurde ich nach langer Suche in der News- 
group comp.unix.amiga auf eine offenbar 
vollständige Datensammlung von AMIX 2.1 
hingewiesen. Ich konnte sie am 02. April 
2002 von der Homepage www.mm- 
hart.com/amix.htm herunterladen. Leider 
wollte die Installationsdiskette partout nicht 


mit meinem Amiga und meinem A3070 
Streamer zusammenarbeiten. Lange such- 
te ich erfolglos nach einer Lösung. Erst vie- 
le Jahre später stellte sich heraus, dass der 
veraltete SCSI-Chip in meinem Amiga das 
Problem war. Es gibt mehrere Revisionen 
des Chips von mehreren Firmen. Die spä- 
tere Version von Western Digital scheint zu 
funktionieren, während die an sich bauglei- 
chen Chips von AMD aufgrund fehlender 
Angaben zur Revision auf dem Gehäuse 
ein Glückspiel sind. Da mein Streamer sich 
aber zwischenzeitlich mit einem zumindest 
für mich nicht reparablen Hardwarescha- 
den verabschiedet hatte stellte ich meine 
Bemühungen im Jahr 2002 ohne Erfolg ein. 
Die Installationsdateien lagerte ich frustriert 
auf eine alte Festplatte aus, die ich im Kel- 
ler lagerte. 

Zwei Jahre später wollte ich endlich AMIX 
auf meinem Amiga installieren. Frischen 
Mutes machte ich mich ans Werk und such- 
te im Internet neue Hinweise. Da ich zuvor 
ja an der Installation gescheitert war, hoff- 
te ich auf Erfolgsberichte anderer Nutzer, 
die ich dann nur noch nachzuvollziehen 
brauchte. Das einzige, was ich fand, wa- 
ren scharenweise Hinweise darauf, dass 
die Homepage, von der ich die Installati- 
onsdateien geholt hatte, vom Netz gegan- 
gen war und die Installationsdateien nir- 
gendwo verfügbar waren. Niemand schien 
sich Kopien der Daten gezogen zu haben, 
und so war AMIX nach landläufiger Mei- 
nung seit zwei Jahren verschollen. Es müs- 
sen noch Original-Bänder existieren, aber 
deren Besitzer haben wohl das Geschehen 
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nicht verfolgt, so dass diese Daten nicht 
verfügbar waren. Aber Moment, hatte ich 
nicht diese Festplatte in den Keller gelegt? 


Auftritt AMIX, zweiter Akt 


Tatsächlich konnte ich alle zur Installati- 
on benötigten Dateien von meiner Festplat- 
te sichern. Der Kernel auf der ersten 
Installationsdiskette konnte booten und 
auch das Installationsskript auf der zwei- 
ten Diskette schien zu funktionieren — bis 
es auf den nicht mehr vorhandenen Strea- 
mer zugreifen wollte. Leider war es mir 
dann nicht möglich, einen Streamer aus- 
zuleihen. Ich musste also eine andere Lö- 
sung finden. Zuerst begann ich zum 
Datenaustausch SCSI-Festplatten zwi- 
schen meinem Linuxrechner und dem Ami- 
ga hin- und herzuwechseln, was mir 
irgendwann aber zu aufwändig wurde. Es 
war mir nämlich gelungen, Daten mit Hilfe 
des Programms dd unter Linux direkt und 
unter Umgehung von Partitionen auf eine 
externe Festplatte zu sichern. Auf dem Ami- 
ga konnte ich nach dem Abbruch des In- 
stallationsskriptes darauf zugreifen. Nur 
musste für jede Datei der Umbaureigen ein 
Mal vollständig durchlaufen werden - für 
jeden Versuch, immer und immer wieder, 
bis der Datenaustausch funktionierte — und 
dann für jede Datei erneut. 

Durch den günstigen Kauf eines zweiten 
ZIP-Laufwerks von lomega hatte ich dann 
eine gute Möglichkeit gefunden, Daten oh- 
ne jeweiliges Herunterfahren und neu Boo- 
ten zwischen beiden Systemen auszutau- 
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schen. So konnte ich eine Menge Zeit und 
Aufwand sparen. Und es gelang mir durch 
Inspektion des Installationsskripts und 
durch Ausgabe von Variablen auf dem Bild- 
schirm herauszufinden, wann das Skript 
welche der 29 Dateien auf dem Tape er- 
wartete. Auch konnte ich so ermitteln, was 
es dann mit der Datei tat, und auch, was 
es mit dem Amiga und seinen Festplatten 
machte. Der Rest lief dann fast wie am 
Schnürchen. Aber eben nur fast, denn ein 
etwas kurioses Problem hielt mich noch ei- 
ne Weile auf. So war es notwendig, zur In- 
stallation zwei Programme auf der Konsole 
mit Hilfe des sogenannten Pipe-Zeichens 
„|“ zu verknüpfen. Dies ist unter Unix üblich 
und die Installationsdiskette war ja eine er- 
ste kleine Unix-Umgebung auf dem Amiga. 
Um Platz zu sparen, hatte ich in meinem 
Arbeitszimmer mehrere Systeme mit Hilfe 
eines KVM-Switches an nur einen Monitor, 
eine Tastatur und eine Maus angeschlos- 
sen. Aber ausgerechnet mein Amiga-Tas- 
taturadapter konnte das Pipe-Zeichen nicht 
erzeugen. Eine Einkaufstour später war 
auch dieses Problem gelöst. Allerdings be- 
kam ich AMIX nicht installiert, weil ich das 
Installationsskript nicht nachvollziehen 
konnte. 


Finale 


Es hatte sich ein weiterer Amiga-Nutzer 
in den USA gefunden, der auch unbedingt 
auf seinem Amiga AMIX installieren wollte. 
Ich schickte ihm nachts per Mail alle Fort- 
schritte, die ich erreicht hatte, und er 
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Wikipedia zu AMIX 

AMIX (Amiga UNIX) ist ein kommerzielles Unix-Be- 
triebssystem der Firma Commodore und speziell auf die 
‚Amiga-Rechner der Firma ausgerichtet. In den 1990er- 
Jahren entwickelt, galt das 68k-basierende Unix-Derivat 
als eine der besten Implementierungen von System V 
R4, die seinerzeit verfügbar waren. 

Das Betriebssystem gab es für den Amiga 2500 (ein 
Amiga 2000 mit 68020-Karte mit PMMU bzw. später 
68030-CPU und A2091-SCSI-Karte) und in Folge auch 
für den Amiga 3000. Es wurde von Commodore als 150 
MByte-Bandkassette für ein externes SCSI-Band- 
laufwerk A3070 ausgeliefert. 

Eingesetzt wurde das System lediglich kurze Zeit auf 
den 68030-basierenden Amiga 2500-UX- und Amiga- 
3000UX-Modellen - danach wurde die Entwickler- 
mannschaft aufgelöst und die Vermarktung eingestellt. 
Es gab davor die Chance, über einen namhaften Work- 
station-Hersteller eine größere Zahl Maschinen als 
OEM-Ware zu verkaufen - was jedoch nie eintrat: Sun 
bot Commodore an, die A3000- und A4000-Reihe 
zusammen mit einem UNIX-Betriebssystem als Low- 
End-Ergänzung zu Suns Workstations zu vermarkten. 
Commodore lehnte dankend ab und verpasste damit 
nicht nur ein potentiell gutes Geschäft, sondern nach 
Ansicht vieler Beobachter auch die Gelegenheit, das 
kommerzielle Image seiner Amiga-Reihe zu heben. 


schickte mir einige Stunden später seine. 
Am 20. Februar 2004 war es dann so weit: 
ich konnte meine erfolgreiche AMIX-Instal- 
lation in der Newsgroup comp.unix.amiga 
verkünden und erste Hinweise für Nachah- 
mer geben. 


Kleinere Nachwehen 


Als letzte Aufgabe blieb nur noch die In- 
stallation des Kernels und des Bootblocks. 
Ich löste dies, indem ich /etc/profile (das ist 
das Installationsskript) wiederum per Zip- 
Diskette in meinen Linux-Rechner kopiert 
und dort bearbeitete. Dies bedeutete, alles 
zu entfernen, was Pakete entpackt, Parti- 
tionen formatiert, prüft und installiert. Das 
bearbeitete Script wurde zurück kopiert und 
unter AMIX ausgeführt. 

AMIX 2.1 lief nun, aber mit zwei Wer- 
mutstropfen: Zum einen war es nicht die 
letzte erhältliche Version 2.1c. Zum ande- 
ren war noch kein Treiber für meine Gra- 
fikkarte Picasso Il installiert. Das erste 
Problem war schnell gelöst, denn es gibt 
eine Patchdiskette, mit deren Hilfe AMIX 
2.1a auf 2.1c aktualisiert werden kann. Das 
zweite Problem löste ein X Server, den 
Klaus Burkert einige Jahre zuvor auf der 
Gateway Vol. 2-CD veröffentlicht hatte. Bur- 
kert arbeitete bei Village Tronic und war 
verantwortlich für das Hardware Design der 
Grafikkarte "Picasso Il". AMIX war sein 
Hobby, und so schrieb er ein halbes Dut- 
zend X Server für einige Grafikkarten. 
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Rückblick im Unmut 


Welches Resümee bleibt in der Bewer- 
tung der Handelnden bei Commodore üb- 
rig? Mit zwei Unix-Varianten im Verkauf und 
einer kurz vor der Veröffentlichung stehen- 
den Vorläufervariante hatte das Manage- 
ment alle Fäden in der Hand, um endlich 
wieder in die Business-Liga vorstoßen zu 
können. Nach dem Erfolg von VC20, C64 
und dem leider weitgehend als Spielekon- 
sole vermarkteten Amiga wäre dies eine 
große Chance gewesen. Dort hätten der 
Umsatz und die Margen für eine Stabilisie- 
rung der stark schwankenden Geschäfts- 
zahlen sorgen können. Nachträglich alles 
besser zu wissen ist natürlich einfach, aber 
drei Teams offenbar weitgehend unabhän- 
gig voneinander an einer jeweils eigenen 
Unix-Implementierung arbeiten zu lassen 
und dabei auf unterschiedliche Unix-Vari- 
anten zu setzen, erscheint nicht als kluge 
Geschäftsidee. Eines der Teams war so 
gut, dass die Firma SUN Microsystems ger- 
ne Amiga 3000UX unter dem Label „SUN“ 
verkaufen wollte. Doch Commodore lehn- 
te dies sogar zwei mal ab, was rückblickend 
nur fassungslos machen kann. 

Zum Entwicklungssystem, mit dessen 
Hilfe AMIX programmiert wurde, kursiert 
eine Geschichte ohne Quellenangabe: Der 
Konkursverwalter soll von Commodore 
nachvollziehbarerweise die Anweisung ge- 
geben haben, aus allen im Lager herum- 
liegenden Teilen so viele verkaufsfähige 
Computer zusammenzubauen wie mög- 
lich. Ein Techniker soll daraufhin die einzi- 
ge Festplatte, auf der der gesamte Quell- 
code für AMIX 2.1 noch verfügbar war, in 
einen IBM-kompatiblen Computer verbaut 
und Windows 3.1 installiert haben. Dadurch 
gingen die ursprünglichen Daten natürlich 
für immer verloren. An Symbolkraft ist die- 
se Geschichte natürlich kaum zu überbie- 
ten. 

Leider wurden also über viele Jahre alle 
Chancen zu Unix bei Commodore vertan, 
und bis auf AMIX sind diesbezügliche Ak- 
tivitäten nur noch einem kleinen Kreis von 
Retro-Begeisterten bekannt. Schade, denn 
die spannende Geschichte hätte es eigent- 
lich verdient, öfter erzählt zu werden. 


AMIX - es gibt Hoffnung 


Heute ist die Installation von AMIX zum 
Glück dank einiger Aktivisten viel leichter 
geworden, und es ist trotzdem nicht weni- 
ger faszinierend als vor zwei Jahrzehnten. 
Installationsdateien und die Anleitung gibt 
es ebenso wie gepatchte Installationsdis- 
ketten, die es ermöglichen, auch ohne den 
Streamer in den Genuss von AMIX zu kom- 
men. Natürlich lässt sich AMIX auch im 
Emulator WinUAE installieren, Hinweise 
und vorbereitete Installationsdateien gibt 
es unter den Links am Ende des Artikels. 


Aber ein echter Amiga bleibt natürlich die 
Königsklasse. 

Für den Amiga gibt es auch Linux und 
NetBSD in aktuellen Versionen. Aber bei 
beiden Betriebssystemen ist der Amiga nur 
eine von vielen Möglichkeiten, es zu instal- 
lieren. AMIX hingegen ist ausschließlich 
unter Amiga oder Amiga-Emulation lauffä- 
hig und deshalb technisch wie historisch 
spannender. Ich würde mich deshalb sehr 
freuen, wenn dieser Artikel den einen oder 
anderen anregen würde, sich mit AMIX zu 
beschäftigen und dieses spannende Be- 
triebssystem durch die Installation auf ei- 
nem Amiga ein weiteres Mal aus seinem 
Dornröschenschlaf zu erwecken. 


Quellen 


Beschreibung UXS Il: Comm, das Maga- 
zin für Commodore Hardware Anwender, 
Ausgabe 2/1991, Seite 18 

LKW-Logistik: Comm, das Magazin für 
Commodore Hardware Anwender, Ausga- 
be 1/1991, Seite 15 


Links 


httops://de.wikipedia.org/wiki/AMIX 
http://www.amigaunix.de/ 
httos://www.amigaunix.com/ 
https://www.amigaunix.com/doku.php/ 
history 
https://forum.amiga.org 

Installationsanleitung für AMIX: 
https://www.amigaunix.de/installation.html 

AMIX im Emulator: 
https://www.amigaunix.com/doku.php/ 
installation 
http://www.vintagebytes.de/ 
downloads.html 

WSX Il als UUCP Server: 
https://groups.google.com/g/ 
sub.lists/c/Dq1GKndVKT4 


8 AMIX und weitere Treiber 


ty finden sich auf der Heft-CD 


HP Apollo 9000 Serie 715 


Die PA RISC Story 


1986 war aus der Sammlerperspektive gesehen ein be- 
deutsames Jahr für die Firma Hewlett Packard. Gegrün- 
det an der Westküste der USA, hatte das Unternehmen 
damals mit High End Geräten und dem wissenschaftli- 
chem Gerätebau eine guten Stand. Aber HP entwickelte 
auch Ambitionen, in das ganz große Computergeschäft 


einzusteigen. 


setzte HP alles auf eine Karte und war 

zum Erfolg verdammt. 1986 erschie- 
nen die ersten vorzeigbaren Rechner - der 
Business Rechner HP 3000 930 und die 
technische Rechenmaschine HP 9000 Mo- 
del 840. Beide basieren auf der neuen ei- 
genen RISC Architektur namens PA-RISC. 


| m Rahmen des Projektes "Spectrum" 


Buntes Durcheinander 


Bis wirklich größere Mengen bei den 
Kunden landen, dauerte es aber dann doch 
noch ein Weilchen. Aber HP hatte den 
Sprung geschafft. Ziel der Geräte aus dem 
Projekt Spectrum war nichts weniger als 
die Vereinheitlichung der kompletten Com- 
puterlinie bei HP. Dies sollte unter einer 
komplett neuen CPU passieren, aufgebaut 
nach dem neuen RISC Architekturkonzept, 
dessen Praxistauglichkeit noch nicht wirk- 
lich erwiesen war. Vorher gab es bei HP je- 
de Menge unterschiedliche Geräte und 
Produktlinien mit jeweils eigenen und zu- 
einander inkompatiblen Prozessoren. Ne- 
ben den CPUs der Maschinen der HP 3000 
Business Reihe gab es vor allem auf dem 
Motorola 68000-Chip basierte Geräte (die 
200 Series) und die neue HP Vectra-Rei- 


he auf Intel 80286 CPUs. Daneben exis- 
tierte auch die 500 Series mit dem FOCUS 
Chip, ein an sich genialer Chip, aber mit 
schwierigen Wärmeproblemen und daher 
nicht (wie ursprünglich gedacht) überall 
nutzbar. 

Dabei reicht die Idee der Entwicklung ei- 
ner performanten und großen CPU bei HP 
bis ins Jahr 1969 zurück. Dieses Jahr setzte 
für sich wichtige Wegmarken: Menschen 
landeten erstmals auf dem Mond und da- 
für war Technik von HP durchaus bedeut- 
sam. Auch die UNIX Entwicklung begann 
1969 und ohne UNIX hätte der RISC Boom 
vermutlich nicht stattgefunden, zumindest 
nicht so explosiv. 

1969 hatte HP mit dem Projekt Omega 
begonnen, eine ambitionierte 32 Bit-CPU 
zu bauen, diese Entwicklung aber wieder 
fallenlassen. Verschiedene Entwickler wa- 
ren damit gar nicht einverstanden . In der 
Folge entstand das Projekt Alpha und als 
dessen Ergebnis eine 16 Bit-CPU. Im spä- 
teren Projekt FOCUS entstand bis 1982 die 
weltweit erste 32 Bit Single-Chip-CPU. Zu 
deren Entwicklung gehörte ein kompletter 
Chipsatz mit Memorycontroller, I/O Control- 
ler und 128 kBit großem RAM Chip. 


Das PARISC Projekt 


Insbesondere Joel Samuel Birnbaum, 
der 1980 zu HP kam und dort 1984 zum Vi- 
ce President und Chef der HP Labs wurde, 
fördert die Idee, RISC als neue Variante 
überall bei HP zu benutzen. Er selbst wech- 
selte vom IBM Forschungszentrum, wo im 
Projekt 801 (benannt nach dem Gebäude 
801) die Idee eines RISC Computers ur- 
sprünglich entstanden war. Birnbaum be- 
teiligte sich in seiner Zeit bei IBM auch an 
der Entwicklung der ersten RISC Compu- 
ter des Konzerns. 

Bei HP wurde zwischen 1982 und 1986 
das Projekt Spectrum aufgesetzt, dessen 
Ziel die Vereinheitlichung sämtlicher nicht 
PC kompatibler Geräte auf einer gemein- 
samen Basis war - der Precision Architech- 
ture, kurz PA-RISC. Dazu trugen alle 
Abteilungen der Firma HP bei, indem sie 
eine Art firmeninterne Abschlagszahlungen 
komplett an das RISC-Projekt abgaben. 
Sollte das Projekt Spectrum nicht zu einem 
brauchbaren Ergebnis führen, wäre HP oh- 
ne eigene CPU dagestanden und wäre fi- 
nanziell ausgeblutet gewesen - ein riskan- 
tes Spiel. 

Aber 1986 gelingt der Quantensprung, 
die erste PA-RISC-CPU ist serienreif. Ab 
1937 werden zunächst die wichtigen Busi- 
ness Computer HP 3000 umgestellt und 
die HP 9000 840 mit PA-RISC-Chips ge- 
fertigt. Ab 1991 folgen dann endlich auch 
die neuen HP Apollo 9000 Desktop Com- 
puter mit der Bezeichnung Series 700. 


Die PA RISC CPU im Detail 


Die ersten Computer der Series 700 ba- 
sieren auf dem PA-RISC-32 Bit Prozesso- 
ren mit 32 Registern (RO bis R31) für Integer 
Zahlenwerte. Die Register sind zwar prin- 
zipiell frei verwendbar, aber es gibt seitens 
HP bestimmte Zuordnungen, wofür welche 
Register zu benutzen sind. So werden et- 
wa die Register R26, R25, R24, R23 zur 
Übergabe von Werten an Subroutinen be- 
nutzt. Ergebnisse von Funktionen werden 
per Definition in R28 zurückgegeben oder 
bei 64 Bit Ergebniswerten in R28 und R29. 
Für die Beachtung solcher Regelungen ist 
der zum System passende Compiler zu- 
ständig. Allen Geräten ist nämlich gemein, 
dass sie nicht mehr per Hand und in As- 


Titelthema Workstations 


Die praktische Klappschatulle — das Gehäuse der Serie 715 wird nach rechts aufgeklappt 


sembler programmiert werden, sondern auf 
Hochsprachen und Compiler setzen. Dort 
werden auch Dinge optimiert, die woanders 
als Demo-Tricks durchgehen würden. So 
werden etwa Multiplikationen vom Compi- 
ler in geschickt angeordnete Folgen von 
Bitschiebeoperationen und Additionen auf- 
gelöst, was schneller geht als das Multipli- 
zieren durch die CPU. 

Bei den PA-7000 sind auch noch die CPU 
und die FPU (mathematischer Coprozes- 
sor) zwei getrennte Chips. Die FPU ist al- 
so extern, was nach sich zieht, dass die 
ersten Desktop Rechner der Series 700 
keine sogenannte Superskalarität beherr- 
schen. Das betrifft die beiden kleineren 
720- (S0MHz) und 730-Systene (66MHz) 
sowie die großen 750-Systeme (66MHz 
und mit bis zu 192 MByte RAM, statt nur 
64 MB). Sie können also nicht in einem 
Taktzyklus eine Integer-Berechnung und 
eine Fließkomma-Berechnung gleichzeitig 
ausführen. Spätere technische Desktops 
wie die 715-Serie lernen das aber bald. 

Ein wesentliches Merkmal von PA-RISC 
und eine Grundidee der Architektur ist der 
Verzicht auf gestaffelte Caches, weil ein 
sehr großer Level-1 (L1) Cache zwischen 
CPU und RAM benutzt wird. Daher hat be- 
reits die PA-7000 CPU einen L1 Daten-Ca- 
che von 256 KByte und einen davon 
getrennten Instruktionscache für die eigent- 
lichen Befehle von ebenfalls 256 KByte. 
Zum Vergleich: Eine 68030 CPU hat einen 
L1 Cache von lediglich 256 Bytes für Da- 
ten und 256 Bytes für Instruktionen. Eine 
ARMS CPU hat 4 kByte Cache ohne eine 
Trennung von Daten und Befehlen. Eine 
80486 CPU besitzt üblicherweise 8 KByte. 
Dafür sind diese bei allen diesen Chips auf 
dem CPU Die integriert. 

Bei HP wächst der verwaltbare externe 
L1 Cache bereits in der Nachfolgegenera- 
tion auf gewaltige 2 MByte für Daten und 
1 MByte für Befehle an, wenngleich dieses 
Maximum in den Desktop Rechnern nicht 
installiert wird. Bei der PA-7100-CPU wird 
die FPU in die CPU integriert, womit sich 


die Möglichkeit ergibt, "2-Wege superska- 
lar" zu rechnen. Im besten Fall kann die 
CPU also immer eine Integerberechung 
und eine Floating Point Berechnung gleich- 
zeitig abarbeiten. Außerdem steigt die Takt- 
rate an, 100 MHz werden möglich. Diese 
CPU findet sich in dem 1992 erschienen- 
en Topmodell "HP 9000 Model 735/99" und 
wird später als PA-7150 noch auf 125MHz 
beschleunigt, dann als Modell 735/125. Der 
Einstandspreis lag bei schlappen 30.0000 
US-Dollar, was dem Gegenwert eines 
ziemlich großen Luxuswagens dieser Zeit 
entspricht. 

Die etwas langsameren CPUs finden sich 
dann im Model 725 wieder und in der Mo- 
dellreihe 715. Dabei ist die 725 eigentlich 
eine 715 im Gehäuse der HP Vectra PCs, 
wodurch Platz für mehr Erweiterungen vor- 
handen ist. 


Die Serie HP Apollo 9000 715 


Der eigentliche Star dieser Zeit ist aber 
wohl die HP 9000 Model 715. Gewisser- 
maßen die "Brot-und-Butter" Workstation 
mit 5.700 US-Dollar für 33 MHz, 14.000 
US-Dollar für 50MHz und 17.300 US-Dollar 
für 75MH2. Die Geräte dieser ersten Rei- 
he sind auch genau danach benannt: 
715/33, 715/50 und 715/75. In alle Model- 
le der Serie 715 lassen sich 256 MB RAM 
einbauen, nur das ganze kleine Modell 
715/33 muss mit 192 MByte auskommen. 
Dabei haben im Jahr 1992 sicher die we- 
nigsten Anwender soviel Speicher instal- 
liert. Üblich waren eher 64 MByte oder 96 
MByte - und das war bereits sehr viel, denn 
ein Standard-PC aus der Zeit hatte 4MB 
oder 8MB. 

Die 715er sind richtig echte Desktop 
Computer mit ein wenig mehr Tiefe, aber 
eben keine Ungetüme in Maß und Gewicht 
und finden daher schön Platz auf dem 
Schreibtisch. Sie haben ein interessant ge- 
bautes Gehäuse, das sich seitlich entrie- 
geln und dann nach oben aufklappen lässt. 
Ein bisschen erinnert das an einem Com- 
modore PET, aber das HP Gehäuse öffnet 


sich von links nach rechts und oben und 
nicht von vorne nach hinten und oben. In 
geöffnetem Zustand lässt sich eine weite- 
re Festplatte nachrüsten oder eine Erwei- 
terungskarte einbauen - etwa eine Grafik- 
karte, mit der dann zusammen mit der 
in-board Grafik zwei große Monitore ange- 
steuert werden können. Das ist perfekt für 
CAD und große Datenmengen. 

An der Frontseite findet sich ein Lauf- 
werkslot, in den etwa ein Streamer, eine 
Floppy oder ein CD-ROM Laufwerk pas- 
sen. Eventuell braucht es dafür ein passen- 
des Plastikteil mit Öffnung, ein heute 
schwierig zu beschaffendes Teil. Ohne 
Laufwerk ergibt sich eine extrem elegante 
Gehäusefront. Da die 715 ja schließlich ei- 
ne Workstation ist, fehlt auch ein externer 
SCSI Anschluss für externe Laufwerke 
nicht. 

Die Rückseite hat neben einem Strom- 
anschluss und dem SCSI Port einen par- 
allelen und zwei serielle Anschlüsse, einen 
AUI Anschluss für einen Ethernet Transcei- 
ver und einen VGA Monitoranschluss für 
die in-board Grafik. Dankenswerterweise 
sind daran direkt VGA Monitore nutzbar, da 
die Sync Signale den üblichen Standards 
entsprechen. Die einzige echte Besonder- 
heit ist der Keyboard- und Mausanschluss, 
denn hier kommt Hewlett Packards HIL 
(Human Interface Link) Schnittstelle zum 
Einsatz. HP HIL ähnelt dem Apple Desktop 
Bus (ADB) oder auch USB, ist aber natür- 
lich zu diesen nicht kompatibel. Es braucht 
also ein spezielles Keyboard und eine pas- 
sende Maus. Die Modelle 33, 55 und 75 
können nur HP HIL, die späteren Baurei- 
hen 64, 80 und 100 besitzen anstelle der 
HP HIL Buchse einen SMB-10 Konnektor 
und führen damit PS/2 und HP HIL Proto- 
koll heraus. Eine externe Zusatzbox dient 
dann als Splitter und ermöglicht es, sowohl 
PS/2 Tastatur und Maus als auch HP HIL 
Eingabegeräte wie Grafiktabletts zu ver- 
wenden. 


Das Betriebssystem HP-UX 


Auf der Serie 715 wird üblicherweise 
UNIX in der HP-Variante installiert, es muss 
HP-UX ab Version 9.00 sein. Die erste Bau- 
reihe 715 wird von HP-UX bis zur Version 
10.30 unterstützt. Alternativ geht aber auch 
Linux für PA-RISC, allerdings wird das heu- 
te ebenso wenig weiterentwickelt wie ein 
HP-UX von 1992. Außerdem lässt sich 
NetBSD als NetBSD/hppa verwenden und 
NexTSTEP in der Version 3.3 ist für HP 
und Sun SPARC Maschinen benutzbar. 

HP-UX ist ein bemerkenswert nutzer- 
freundliches System. Es kommt HP VUE 
und in späteren Versionen mit dem CDE 
Desktop daher und nutzt das Programm 
SAM als Oberfläche für die Administration. 
SAM erlaubt es, sämtliche wichtigen Din- 


Mit SAM erledigt der HP-UX Administrator fast alle Aufgaben. 


ge per Maus einzustellen: ob nun neue User 
angelegt werden müssen, ein wöchentli- 
ches Backup einzurichten ist, die Bild- 
schirmauflösung geändert werden soll oder 
am Netzwerk geschraubt wird. Das geht 
sogar soweit, dass sich veränderbare Ker- 
nel Parameter einstellen und per Mausklick 
ein neuer Kernel generieren lässt. Dieser 
wird dann beim nächsten Booten geladen 
— bei Fehlern ist es gut, eine Kopie vom 
Original erstellt zu haben. Das System fühlt 
sich insgesamt auch heute noch schnell an 
und insbesondere auch die Textdarstellung 
im Editor ist bemerkenswert flott. 


Die späteren Modelle 


Besonders gilt das aber natürlich für die 
zweite Baureihe der 715 aus dem Jahr 
1994. Die Modelle werden auch in der 
1994er Reihe nach den Taktfrequenzen be- 
nannt, nämlich als 715/64, 715/80 und 
715/100. Hierbei ändert sich am Gesamt- 
aufbau des Gerätes nichts wesentliches, 
allerdings ist eine Weiterentwicklung der 
CPU verbaut. Das direkte kleinere Schwes- 
termodell zur 715 ist die 712 - die "Gecko". 
Ihr Designmotto lautet "More Style, Less 
Space", denn das Gehäuse ist deutlich klei- 
ner. Sie kennt nur PS/2 Anschlüsse für 
Maus und Tastatur. 

Die PA-7100LC CPU ist hauptsächlich 
kostenoptimiert (LC steht für "low cost"), 
hat aber trotzdem Vorteile. Die Kostensen- 
kung wurde nicht durch einen geringeren 
CPU Takt erreicht; hier sind bis zu 100 MHz 


möglich. Vielmehr ist HP hier vom teuren, 
großen externen L1 Cache abgerückt. 
Stattdessen ist ein kleiner, 1 KByte großer 
L1 Cache nur für Instruktionen auf der CPU 
eingerichtet, dafür ist ein externer, mit bis 
zu 2 MByte auch recht großer Level-2 Ca- 
che vorhanden. Dieser ist auch noch "uni- 
fied", wird also für Daten und Befehle 
gleichzeitig genutzt. Das spart die teuren 
L1 RAMSs, gleichzeitig ist so die komplette 
Memoryverwaltung und auch der I/O Con- 
troller in die CPU verlagert. Die CPU hat 
außerdem ein zusätzliches Rechenwerk für 
Integerzahlen, also zwei Integereinheiten 
und ein Floating Point Rechenwerk. Immer 
zwei davon lassen sich parallel benutzen, 
also entweder zweimal Integer- oder einmal 
Integer plus Floating Point Rechenwerk. 
Die CPU arbeitet also Superskalar. Außer- 
dem kennt die PA-7100LC-CPU eine rudi- 
mentäre Sprungvorhersage. Mit MAX-1 
bietet sie zudem eine Multimedia Erweite- 
rung, mit der SIMD und damit das Abspie- 
len von MPEG-Videoclips möglich wird. 


Fazit 


Hewlett Packard hat mit den PA-RISC- 
CPUs und den Serien 700 sein Ziel erreicht, 
die eigenen Computer auf eine gemeinsa- 
me CPU Basis zu stellen. Die Geräte wa- 
ren in den 1990er Jahren in Forschung und 
Lehre, aber auch in der IT generell weit ver- 
breitet. HP OpenView als beliebtes Netz- 
managementsystem lief ebenso auf den 
Maschinen wie medizinische und techni- 


TR 


sche Anwendungen. Die PA-7150 als eine 
verbesserte, höher zu taktende PA-7100 
sollte die Basis des Commodore „Hombre“ 
Chipsatzes werden und die wichtige 
Grundlage für einen AMIGA Nachfolger . 
Daraus ist bekanntermaßen nichts mehr 
geworden. 

2008 endete auch die PA RISC Ge- 
schichte bei Hewlett Packard und gemein- 
sam mit Intel startete die Itanium-Reihe. 
Doch das ist eine andere Geschichte. 


Links 


http://www.hpmuseum.net/ 
https://www.openpa.net/ 
http://www.robelle.com/library/smugbook/ 
http://www.parisc-linux.org/ 
https://parisc.wiki.kernel.org/ 
index.php/Main_Page 
https://www.youtube.com/watch? 
v=DIccem’H30A08&t=296s 

PA RISC CPU | 
http://www.hpl.hp.com/hpjournal/pdfs/ 
IssuePDFs/1986-08.pdf 
https://www.hpl.hp.com/hpjournal/pdfs/ 
IssuePDFs/1987-03.pdf 
https://www.youtube.com/ 
watch?v=C53tGHzp1PI 

Modelle: 
https://archive.org/details/ 
hp_journal_1992-08/mode/2up 
https://archive.org/details/ 
hp_journal_1992-06/mode/2up 
https://archive.org/details/ 
hp_journal_1995-04/mode/2up 
https://www.youtube.com/watch? 
v=ERJPUDCBGZg 
https://www.youtube.com/watch? 
v=hBn5U5xAd3Y&t=68s 

PowerShift Werbung 
https://www.youtube.com/watch? 
v=VLTh4uVJaul 


Ueber den Autor 


Sebastian Barthel ereilte nach 
einer gluecklichen analogen 


Kindheit der digitale Fluch in 
Form eines Plus/4. BASIC, 
Assembler, Pascal und andere 
folgten. Das Thema blieb 
immer irgendwie interessant. 
Die Rechner aber sind 
momentan eher Workstations 


und Raspberries. 
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Schritt-für-Schritt Anleitung 


Sun Ultra-1 neu 


installieren 


Noch ist das Angebot an SUN-Workstations recht groß. 
An eine eigene Maschine zu gelangen, ist also nicht 
unmöglich. Was aber, wenn die Festplatte fehlt oder der 


Vorbesitzer sie gelöscht hat? Dann ist eine Neuinstallation 
des Betriebssystems unumgänglich. Wie das geht, zeigen 


wir am Beispiel einer SUN Ultra-1 


EEE ZT 


a 


ie Ultra-1 ist zusammen mit der 

Ultra-2 der Startpunkt der Ultra- 

SPARC Reihe. Sun hat diese Rei- 
he 1995 gestartet und bis zum Firmenende 
im Jahre 2010 weiter gebaut. Die Ultra- 
SPARC-Prozessoren haben eine 64-Bit 
Architektur, sind aber abwärtskompatibel zu 
ihren 32-Bit Vorgängern. Sie sollten Sun 
wieder auf Augenhöhe mit der Konkurrenz 
von HP, SGl oder DEC bringen, insbeson- 
dere in Bezug auf die Rechenleistung. Die 
Prozessoren sind auf Multiprocessing aus- 
gelegt. Sie ermöglichen große Server, wie 
das anbrechende Internet-Zeitalter sie da- 
mals forderte. 

Auch die eingebaute Unterstützung für 
Mediendaten (VIS) geht in diese Richtung: 
VIS (Visual Instruction Set) ist eine Instruk- 
tionssatz-Erweiterung und wurde mit dem 
UltraSPARC-I-Prozessor eingeführt. Die 
Fließkommaeinheit (FPU) und die Grafik- 
einheit (GRU) sind die Einheiten (Unit) auf 
dem Silliziumplättchen des Prozessors 


(Die), welche die Verarbeitung der jeweili- 
gen VIS Instruktionen vornehmen. Die Pro- 
zessoren sind volle 64-Bit-CPUs und besit- 
zen FPUs mit Parallelrechenfunktionalität 
(Superskalar). Sie können also mehrere Be- 
fehle aus einem Befehlsstrom gleichzeitig 
mit mehreren parallel arbeitenden Funkti- 
onseinheiten abarbeiten. Dank neuer Fer- 
tigung und großen externen CPU Caches 
(512 KByte) sind hohe Taktfrequenzen mög- 
lich. Die Sun Ultra-Maschinen können dank 
8 RAM-Steckplätzen bis zu 1 GByte RAM 
aufnehmen, für das Jahr 1995 ein sehr gro- 
ßer Wert. Übrigens konnten erst mit Sola- 
ris 7 (SunOS 5.7 mit ONC und CDE) die V9 
Instruction Sets der UltraSPARCs voll aus- 
genutzt werden. Bis dahin musste mit dem 
unter Solaris bekannten vöplusa Binärfor- 
mat für UltraSPARC-Programme ein auf 32 
Bit beschränkter Instruktionssatz der V9 In- 
struction Sets mit VIS 1.0 reichen. 

Es existieren verschiedene Versionen der 
Ultra-1. Wichtige Hauptunterschiede sind 


die Art der Anbindung der Grafikkarte an 
das Gesamtsystem und damit einherge- 
hend unterschiedliche Taktfrequenzen von 
CPU und Bustakt. Bei der Grafik hat das 
recht deutliche Auswirkungen. Der norma- 
le SBus taktet dort mit 25 MHz, der UPA- 
Bus aber 83MHZz. Die beiden anderen wich- 
tigen Unterschiede sind Fast-SCSI-2 bei 
den kleineren U1-Maschinen und Wide- 
SCSI-2 bei den größeren. Die kleinen U1 
verfügen nur über Ethernetschnittstellen mit 
10 MBit/s, die größeren schaffen 100 MBit/s. 
Die Taktfrequenzen der UltraSPARC-CPUs 
können 143 MHz oder 167 MHz oder 200 
MHz betragen. 


Aufbau der Ultra-1 


Die Maschinen wirken recht spartanisch. 
Auf der rechten Seite finden sich CD-Lauf- 
werk und ein normalerweise unbestückter 
Platz für ein Floppy Disk-Laufwerk. Es gibt 
aber nicht einmal eine Status-LED für die 
Festplatten. Zwei 80 Pin SCA-Laufwerke 
lassen sich einbauen, und zwar direkt in ei- 
nem Einschubschacht, ähnlich eines gros- 
sen Servers. Sie werden von einem Lüfter 
gekühlt, der vorne links sitzt und seine 
Frischluft über die Frontleiste holt. Noch 
wichtiger ist die Lüftung quer durch das Ge- 
häuse über zwei große Netzteil-Lüfter. Die 
Maschine muss also entsprechend frei auf- 
gestellt werden, um keinen Wärmestau zu 
verursachen. 

Auf der Rückseite sind oben zwei mar- 
kierte Schrauben zu sehen. Herausgedreht 
ist der Deckel leicht nach oben aufzuklap- 
pen, ähnlich einer Motorhaube. Doch Vor- 
sicht — die Plastikführungen hinten sind em- 
pfindlich, ebenso die kleinen Plastiknasen 
in der Front. Die Rückseite zeigt ansonsten 
die Anschlüsse für Parallelkabel, Tastatur, 
Ethernet (AUI und RJ45), einen 50-poligen 
SCSI-Anschluss und zwei serielle Schnitt- 
stellen. Ist Serial-A per Jumper auf RS-232 
eingestellt, sind alle Boot- und Fehlermel- 
dungen auf einem angeschlossenen Termi- 
nal zu sehen. Ebenfalls auf der Rückseite 
findet sich der 13W3-Anschluss der Grafik- 
karte. 


In Betrieb nehmen 


Wenn man die Geschichte nach Jahren 
der Nichtbenutzung anschaltet, ist im Nor- 
malfall die Batterie im NVRAM-Chip leer. 
Dieser führt bei Sun den eher unangeneh- 
men Namen TOD für "Time Of Day". Abhil- 
fe schafft ein Aufbohren des Chips und der 
Anschluss eines Batteriehalters. Mit etwas 
Glück findet sich aber auch ein neuer Chip 
bei einem Händler, bei dem die Batterie 
noch Strom hat. Sicher ist das nicht — oft 
sind die angebotenen Chips fast genauso 
alt wie der in der Sun. 

Nach dem Einschalten der Maschine 
passiert etwa eine Minute lang scheinbar 
nichts. In Wirklichkeit arbeitet die Sun die 
POST-Tests ab. Nur sind die Ausgaben 
nicht auf der Grafikkarte zu sehen, sondern 
nur über die serielle Schnittstelle. Hängt 
die Maschine also nach dem Einschalten, 
können die Infos dort hilfreich für die Feh- 
lersuche sein. War der Boot erfolgreich, 
meldet sich die Sun mit einem Logo, dem 
Namen der Maschine und Zufallswerten für 
Maschinen-ID und MAC-Adresse. Diese 
Angaben stehen normalerweise im NV- 
RAM, das ja aber mangels Strom aus der 
Batterie seinen Inhalt verloren hat. Dann 
helfen unsere Tipps auf Seite 16, um die 
Mschine zu booten. 

Dann meldet sich das OpenBoot-PROM 
der Sun mit einem lapidaren "OK". Von hier 
helfen einige Befehle weiter: 


"help" listet die möglichen Kom- 
mandos auf 

"devalias" zeigt die vorbelegten 
Namen für Geräte an, die von der 
Maschine vorzufinden erwartet wer- 
den. Das sind hilfreiche Abkürzun- 
gen und ersparen die Eingabe 
langer Devicenamen. 
"show-devs" zeigt alle bekannte 
Geräte an. 

"printenv" würde alle eingestellten 
Werte im NVRAM anzeigen, kann 
aber bei leerer Batterie nur Default- 
Werte zeigen. Interessant sind da- 
bei die Einstellungen für ttya und 
ttyb und das eingestellte Boot-De- 
vice. 

"probe-scsi" fragt den SCSI-Bus 
nach Laufwerken ab. Hier muss zu- 
mindest die vorhandene Festplatte 
zu sehen sein, ansonsten liegt ein 
Fehler bei Platte oder SCSI-An- 
schluss vor. 


Installation 


Die Installation von Solaris erfolgt von ei- 
ner CD-ROM. Dies ist entweder eine Ori- 
ginal-CD oder ein selbst gebranntes ISO- 
Image. Da mit dem Kauf einer originalen 
Sun Maschine zwischen 1982 und 2004 
auch immer eine Lizenz für Solaris einher 
ging, ist dies rechtlich unbedenklich. Die 
Codebasis von Solaris bis zur Version 9 ist 


außerdem in weiten Teilen unter einer 
Open Source-Lizenz (CDDL) veröffentlicht. 
Vom OpenBoot-PROM initiiert das Kom- 
mando boot cdrom den Boot von dieser 
CD. Die Installation erfolgt im Grafikmodus 
mit einer OpenWindows-Oberfläche. 


Schritt 1 


Solaris nennt kurz die anstehenden 
Schritte und verlangt dann die Eingabe ei- 
nes Hostnamens. Dieser sollte sinnvoll ge- 
wählt sein und darf im Netz kein zweites 
Mal vorkommen. Dann fragt der Installer, 
ob eine Netzwerkanbindung erfolgen soll. 
Die Frage wird natürlich bejaht, worauf das 
Programm eine IPv4-Adresse abfragt. Der 
Schritt wird mit einer Zusammenfassung 
der Einstellungen beendet. 


Schritt 2 


Nun will der Installer wissen, welchen 
Namensdienst Solaris verwenden soll. NIS 
und NIS+ wären in einem großen Netz mit 
einem zentralen NIS-Authentifizierungs- 
server sinnvoll. Dieser wird sich Zuhause 
kaum finden. Damit ist "Other" die besse- 
re Wahl; so können wir später einen DNS- 
Server eintragen. Die folgende Frage nach 
Aufstellung in einem Subnetz ist ebenfalls 
in einem Hausnetz ohne weitere Router zu 
verneinen. 


Schritt 1 
Zusammenfassung der Eingaben 


Schritt 2 
Netzwerkeinstellung 


Schritt 3: 
Zusammenfassung der Installationsschritte 


I Confirm Information 


> Confirm the following information. If 
it is correct, 

choose Continue; to change any 
information 

choose Change. 


Host nane: WindknollenupA 
Networked: Yes 
Ip address: 192.168.2.20 


Continue | Change Help | 
Schritt 4: 
Auswahl der Festplatte für die Installation 
use von Disks 


On this screen you must selec Ihe disks for installing Solarıs software. Start by looking at ıhe 
Required field, this value 5 Ihe approximate space needed to install Ihe software you've seleded 
Keep selecling disks until {he Total Selected value exoeeds Ihe Required value 

>To add a disk, select it from Ihe list on the left by clicking on it, and choose Add 


> To remove a disk, selea It Irom the list on right by clicking on it, and choose Remove. 


Available Disks: Selected Disks: 
aaa 
cotıao 3746 MB > 


< Remove 


Total Available: 17492 Recommended: 391 
“ Required: 223 
Total Selected: o 


Subnets 


On this screen you must specify whether 
this system is part of a subnet. If you 
specify incorrectiy, the system will 
have problems communicating on the 
network after you reboot. 


Systen part of a subnet: Yes 


» No 


Help | 


Schritt 5 
Automatisches Partitionslayout 


Automatically Layout File Systems? 


Do you want to use Ihe auto-layout feature to automatically layout file systems? Manually layıng out 
file systems requires advanced system administration skills. 


> To use the auto-layout feature, choose Auto-layout. 


> To manually lay out lie systems, choose Manual Layout 


[sr ] Go Back Manual Layout Exit Help | 


Install Solaris Software = Initial Al 


The screens that follow let you tailor how Solaris is installed on your system 
The main tasks you must perform to install Solaris on your system are 


- Selecting a system type 

- Selecting Solaris software 

- Selecting disks to hold soltware you've seleded 
— Speälfying how files systems are laid out on disks. 


Alter completing Ihese tasks, asummary of your seledions (called a profile) 
s displayed. You can go back and change selections as many times as you 
like before starting to install Solarıs 

>To go to the next screen, choose Continue 


Schritt 6: 
Ergebnis der automatischen Partitionierung 


File System and Disk Layout 


The summary below #5 your current file system and disk layout, based on the 
information you've supplied. 


NOTE Il you choose Customize, you should understand Iile 
systems, their intended purpose on Ihe disk, and how changing 
Ihem may altect Ihe operation ol the system 


> To acoept Ihe layout shown, choose Continue. 
> To astomize Ihe layout, choose Customize. 


File m Disk Size 
c0t0doso 130 MB 
swap corodosı 128 MB 


overlap <orodos2 8746 MB 


Options 


/var cotodos3 110 MB 
Jusr c0rodoss 225 MB 
/export/home cot0dos? 8151 MB 
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Schritt 3 


Wichtig ist die Auswahl der richtigen Zeit- 
zone. Hier führt der Weg über "Geographic 
region" zu einer Auswahlliste, in der "Eu- 
ropa" und "Middle Europe" einzustellen ist. 
Mit der Einstellung von Uhrzeit und Datum 
ist auch dieser Schritt beendet. 


Schritt 4 


Nun geht es an die eigentliche Installati- 
on. Der Installer erfragt die Art des Sys- 
tems, hier haben sich "Stand alone" und im 
nächsten Fenster "End User System Sup- 
port" bewährt. Später lässt sich fehlende 
Software noch nachinstallieren. Zur Instal- 
lation ist hier in der Abbildung die erste Plat- 
te im System ausgewählt, das ist das 
Device c0t0dO. Die Aufteilung der Platte 
überlassen wir dem Installer, das Auto Lay- 
out ist in den meisten Fällen passend und 
bedarf nur bei unverhältnismäßig großen 
Platten einer Anpassung. Hier beschrän- 
ken wir uns darauf, drei Partitionen (hier 
Slices genannt) einzurichten, nämlich swap 
(virtuelles RAM), Root (/) und /usr (unix spe- 
cial ressources). Der Installer erzeugt da- 
für die entsprechenden Partitionen. Wer 
nur das Partitionsschema der MSDOS- und 
Windows-Welt kennt, ist hier wahrschein- 
lich von den Bezeichnungen erst einmal 
verwirrt. Unter Solaris ist Slice O die Root- 
Partition und Slice 1 ist swap. Slice 2 ist ein 
Overlap-Slice, der die gesamte Platte um- 
fasst und nicht direkt angesprochen wird. 
Slice 3, 4 und 5 sind schließlich /usr (Pro- 
gramme), /var (Daten) und /export/home 
(Benutzerverzeichnisse). Jeder Slice hat 
einen eindeutigen Namen, zum Beispiel 
c0tOd0s3 für die /usr- Partition der ersten 
Platte. Es ist auch möglich, die Einstellun- 
gen manuell zu verändern, worauf wir hier 
der Einfachheit halber aber verzichten. 

Nach einer Rückfrage, ob das System 
nach der Installation rebootet werden soll, 
startet der Installationsprozess. Die Instal- 
lation dauert eine ganze Zeit. Der abschlie- 
ßende Reboot wird wieder auf das Open- 
Boot-PROM führen. 


Das neue System booten 


Mit dem Befehl boot disk0O ist die Sun zu 
bewegen, in das neu installierte System zu 
booten. Die Bootmeldungen sind unspek- 
takulär, der Solaris Kernel beschwert sich 


Grafisches Login mit XDM 
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Hille: sydneyait 


Der Lohn der Mühen- Solaris mit OpenWindows 


lediglich (wie aufgrund der leeren Batterie 
zu erwarten) über einen ungültigen Code 
im IDprom. Am Ende des Bootvorgangs will 
Solaris dann ein Passwort für die System- 
verwalterin "root" erfahren. Hier ist der Hin- 
weis wichtig, dass nur die ersten 8 Zeichen 
des Passworts signifikant sind. 

Normalerweise arbeitet der Benutzer un- 
ter Solaris mit einer nicht privilegierten Be- 
nutzerkennung und nicht als System- 
verwalter. Daher gilt es nun, einen solchen 
Benutzer anzulegen. Mit dem Befehl 
useradd -d /export/homef/friedrich -K 
/etc/skel friedrich werden ein Benutzer na- 
mens „friedrich" erzeugt, sein Heimatver- 
zeichnis angelegt und einige Konfigura- 
tionsdateien für ihn dort abgelegt. Ein 
Passwort besitzt der neue Benutzer nicht. 
Das will mit dem Befehl passwd friedrich 
angelegt werden. 

Das System bootet in der hier gewählten 
Konfiguration immer in eine Textkonsole. 
Das bedeutet aber nicht, Solaris würde kei- 
ne grafische Oberfläche mitbringen. Der 
Systemverwalter "root" muss diese nur mit 
dem Kommando /usr/openwin/bin/xdm 
starten. Dies ruft den XWindow Display Ma- 
nager auf und dieser präsentiert ein grafi- 
sches Login-Fenster. Meldet sich der Be- 
nutzer "friedrich" dort an, landet er auf dem 
OpenWindows-Desktop von Solaris. Die 
Oberfläche bietet Dinge wie xclock, das au- 
diotool oder das calctool. Das Starten ge- 
lingt am besten aus dem Menü heraus, das 
sich nach einem Linksklick auf den Desk- 
top Öffnet. 

Damit ist die Sun Ultra-1 also wieder ein- 
satzbereit. Wie Programme installiert oder 


das System auf ein grafisches Login gleich 
nach dem Boot umgestellt wird, lässt sich 
leicht aus den unten angegebenen Quel- 
len recherchieren. 


Links 


Allgemeine Infos: 
https://en.wikipedia.org/wiki/Ultra_1 
Weitere Infos: 
https://en.wikipedia.org/wiki/ 
Ultra_Port_Architecture 

Die alten SunStuff Seite bei Archive.org: 
https://web.archive.org/ 
web/20190513182807/ 
http:/sunstuff.org/hardware/ 
systems/sun4/sun4W/ULTRAT/ 
Restbestände an Doku zur Ultra1 bei 
Oracle: 
https://docs.oracle.com/cd/E19127-01/ 
ultra1.ws/index.html 

Anleitung zum PROM Upgrade: 
https://docs.oracle.com/cd/ 
E19...0-10/6jfrcj1g7/index.html 

NVRAM programmieren: 
https://www.rup 12.net/posts/2021/ 
adventures-with-Sun-ultra-1-workstation/ 


Alternative zu Solaris 


Linux auf Sun 


as aktuelle Solaris 11 läuft nicht 

mehr auf alten SPARC- und Ul- 

traSPARC-Maschinen. Also be- 
gnügt sich der stolze Workstation- 
Besitzer mit Solaris 10 und findet sich 
mit dem spärlichen Angebot an legal her- 
unterladbarer Software ab. Oder die Sun 
bekommt ein zeitgemäßes Betriebssys- 
tem, für das es Software in großen Men- 
gen gibt. Schließlich sind Linux und BSD 
auch für Sun Maschinen verfügbar. 


Das dachte sich auch der Autor und 
machte sich daran, seine Sun Ultra 10 neu 
zu installieren. Mit einer Taktfrequenz von 
333MHZz, 384 MByte RAM, zwei IDE-Fest- 
platten mit je 40 GByte IDE-Festplatte, ei- 
nem LSI SCSI-Controller im PCI-Slot und 
der Creator 3D Karte im UPA-SIlot macht 
die Maschine auch heute noch durchaus et- 
was her. 

Hinsichtlich einer brauchbaren Distributi- 
on ist zwar Auswahl vorhanden, aber es gibt 
auch Fallstricke. Sparc64 hat bei Debian 
GNU/Linux nur den Status "unofficial" und 
die Installations-CD bootet nicht ohne wei- 
teres. Besser ist da schon Gentoo: Die Live- 
CD läuft auch mit 128 MByte RAM. Gentoo 
aber eine Source Distribution, alle Pakete 
kommen im Quellcode und werden erst auf 
der Maschine selbst kompiliert. Das bedeu- 
tet Zeitaufwand und kostet aufgrund des 
Leistungshungers der Sun auch einiges an 
Strom. Ubuntu hat die Unterstützung für 
Sun seit der Version 10.04 (Lucid Lynx) auf- 
gegeben, was nunmehr schon 12 Jahre her 
ist. 

Neben Linux unterstützen aber auch die 
verschiedenen BSD-Distributionen die 
SPARC-Architektur. OpenBSD läuft auf An- 
hieb auf der Ultra 10. Leider funktionierte 
der Treiber für die Creator 3D-Karte im Test 
nicht und die Smartmon Tools kamen mit 
den IDE-Laufwerken nicht zurecht. Free- 
BSD unterstützt in der Version 12 Ultra- 
SPARGC als Tier 2 Architektur nicht vollstän- 
dig und wird den Support in der Version 13 
vollständig aufgeben. Zu guter Letzt ging 
ein Test mit NetBSD völlig schief, die Ver- 
sion lies sich nicht zum Booten bewegen. 

Wirklich glücklich machen die Linux- und 
BSD-Distributionen also nicht. Letztlich fiel 
die Wahl dann doch auf Debian, denn hier 
wird eine komplette 64-Bit-Portierung der 
aktuellen Debian-Version (sparc64) vom 
Debian Ports Team zur Verfügung gestellt. 


Die Installation beginnt mit dem Herun- 
terladen eines ISO-Image des Debian 
sparc64-Installers und dem Brennen auf ei- 
ne CD-R. Leider funktionierte im ersten An- 
lauf auch damit die Installation nicht. Das 
Problem ließ sich auf mangelnde Unterstüt- 
zung der Grafikkarte während der Installa- 
tion zurückführen. Hier hilft ein Kniff weiter: 
Wird die Grafik ausgeschaltet und ein Ter- 
minal an die serielle Schnittstelle ange- 
schlossen, läuft die Installation doch. 
Voraussetzung sind aber mehr als 128 
MByte RAM. Damit der Zugriff vom Termi- 
nal oder einem PC mit einer Terminalemu- 
lation funktioniert, sind ein paar Einstel- 
lungen im OpenBoot-PROM der Sun 
erforderlich: 


auto-boot? false 
input-device ttya 
setenv output-device ttya 
setenv ttya-mode 38400,8,n,1,- 
reset-all 


setenv 
setenv 


Jetzt sollte die an Port A angeschlossene 
Konsole ein Bild zeigen. 

Mit boot cdrom lässt sich die Sun dann 
von der Installer-CD booten. Nach einer 
Weile meldet sich der normale Debian-In- 
staller. Der Rest läuft wie bei jeder Debian- 
Installation ab und soll hier nicht weiter ver- 
tieft werden, da es dazu genügend Doku- 
mentation auf den Debian-Servern gibt. 
Aber auf ein paar Besonderheiten gilt es zu 
achten: 

Aus dem OpenBoot-PROM ist jede Disk 
als Boot Device auswählbar. Damit sind also 
ohne Probleme mehrere Betriebssysteme 
möglich, immer eines pro Festplatte. Bei 
der Installation darf jede vorhandene Platte 
ausgewählt werden. Die erste Partition der 
Platte wird dann zwingend als Bootpartition 
benötigt. 

Das Partitionslayout der Platte ist unter 
Linux anders als bei Solaris. Die erste Par- 
tition ist die Bootpartition, sie wird mit ext2 
formatiert und startet bei Block 0. Im ersten 
Block (512-Byte) liegt die Sun Partitions- 
tabelle, im zweiten der GRUB-Bootblock 
und im dritten dann schon der Superblock 
des Dateisystems. Der restliche Teil von 
GRUB wird dann im Dateisystem einge- 
bettet. Das hat ein paar Konsequenzen. Zu- 
nächst sollte fdisk die Patitionstabelle nur 
mit 


fdisk -w never /dev/sdX 


anfassen. Ansonsten löscht fdisk den 
ext2-Superblock. Das wird fairerweise auch 
angekündigt — stimmt der Anwender zu, ist 
die Partition nicht mehr zu gebrauchen und 
eine Neuinstallation ist fällig. 

Wer GRUB neu installieren will, muss den 
Boot-Loader in die erste Partition installie- 
ren: 


grub-install --skip-fs-probe --\ 
force /dev/sdx1 


Außerdem sollte dazu die Partition 
/dev/sdX1 auf /boot gemountet sein. Wird 
das nicht beachtet, schreibt GRUB in die 
falsche Partition und das System bootet 
nicht mehr. Es empfiehlt sich daher, von der 
Bootpartition ein Image zu machen, 


da if=/dev/sdX1 | 
gzip > bootpartition.img.gz 


das sich bei Bedarf wieder zurück- 
schreiben lässt. 


gzip -cd bootpartition.img.gz | 
ad of=/dev/sdxl1 


Dafür ist es praktisch, wenn die Bootpar- 
tition wie vom Installer vorgeschlagen nur 
um die 500 MByte groß ist. 

Den Treiber für die Creator 3D-Karte gibt 
es nur als Quellpaket. Von der offiziellen 
Debian Seite heruntergeladen, müssen die 
Abhängigkeiten mit apt installiert und mit 


dpkg-buildpackage -b 


das Paket kompiliert werden. Ein dpkg -i 
installiert das fertig kompilierte Paket, 
danach läuft die Creator 3D-Karte ohne 
weitere Konfiguration. Als Window Manager 
und Desktop für das X-Window System em- 
pfiehlt sich Openbox und XDM, diese laufen 
auch mit 384 MByte RAM ohne auf die 
Swap-Datei auszulagern. (r4m/gb) 


Links 


https://forum.classic-computing.de/ 
forum/index.php ?thread/21778-howto- 
aktuelles-debian-auf-sun-ultra-10/ 
&postID=259896#p0st259896 
https://www.debian.org/ports/sparc/ 
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Eine Seltenheit unter den Workstations 


Atari Transputer 
Workstation 


Es gibt seltene Computer, sehr seltene und solche, die absolute 
Raritäten sind. Eines dieser extrem seltenen Stücke ist die Atari 
Transputer Workstation, kurz ATW genannt. Groß ist die Freude, 
wenn es gelingt, dieses seltene Stück zu erwerben. 


ie Atari Transputer Workstation, 

auch bekannt als ABAQ, ATW- 

800 oder einfach ATW war ein 
Computer der Workstation-Klasse. Sie wur- 
de 1989 von Atari herausgebracht und 
basierte auf dem INMOS-Transputer. 
Einige mögen sich vielleicht erinnern, dass 
Transputer in den späten 1980er Jahren 
als das nächste große Ding galten. Sie soll- 
ten das Problem lösen, wie sich die Leis- 
tung eines Computersystems steigern 
lässt, ohne schnellere CPUs entwickeln zu 
müssen. Denn das galt schon damals nur 
bis zu einer bestimmten Grenze als wirt- 
schaftlich machbar. Diese Grenze schien 
im Jahr 2001 erreicht. Anstelle einer großen 
CPU sollten eine beliebige Anzahl von 
kleinen, billigen, aber vollständigen CPUs 
zusammenarbeiten, um die benötigte Leis- 
tung zu erbringen. 

Das Prinzip klingt vertraut — es handelt 
sich im Grunde um dasselbe Konzept wie 
bei den heutigen Multicore-Rechnern. Im 
Unterschied zu diesen sind Transputer aber 
separate Chips ohne gemeinsamen Cache. 
Das macht die Zusammenarbeit der CPUs 
sehr wichtig. Daher erdachten die Entwick- 
ler schnelle Verbindungen zwischen den 
Transputern. Sie vermochten sogar über 
ein einzelnes Computersystem hinaus- 
reichen und verbanden somit mehrere 
Transputer zu einem kombinierten System. 
Die Transputer enthielten einen eingebau- 
ten RAM-Controller, wodurch RAM leicht 
hinzugefügt werden konnte. 

Transputer waren das Produkt eines ein- 
zigen britischen Unternehmens: Die Firma 
Inmos brachte 1985 den ersten Transputer 
heraus. Die Transputersysteme konnten 
sich aber nicht gegen ihre traditionelleren 
Konkurrenten durchsetzen. 1989 wurde In- 
mos an SGS Thomson verkauft. Danach 
wurden die Transputer im Grunde genom- 
men nicht mehr hergestellt. Inmos hat 
während seines Bestehens eine Reihe von 
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https://commons. wikimedia,org/wiki/File:Atari_AWT_800.jpg 


Transputer-CPU-Modellen entwickelt. Eine 
Übersicht ist der Tabelle zu entnehmen. 


Atari goes Workstation 


Der ATW und sein Betriebssystem Heli- 
OS wurden von Perihelion entwickelt. Die- 
se Firma war eine Gründung ehemaliger 
Mitarbeiter von MetaComCo Ltd. aus Bris- 
tol, England. MetaComCo entwickelte un- 
ter anderem mit TRIPOS ein Betriebs- 
system, das später die Basis für das 
AmigaOS werden sollte. MetaComCo hat- 
te gute Verbindungen sowohl zu Atari als 
auch zu Commodore. Perihelion versuch- 


te daher, beide Unternehmen für die Her- 
ausgabe einer Transputer-Workstation mit 
HeliOS zu interessieren. Commodore hat- 
te ein gewisses Interesse an ihrem neuen 
System bekundet. Das Unternehmen zeig- 
te Demos davon auf einer Zusatzkarte, die 
in einem Amiga 2000 lief. Später hat Com- 
modore anscheinend das Interesse daran 
verloren. Zu diesem Zeitpunkt traf sich Ata- 
ri mit Perihelion und die Arbeit begann an 
dem, was schließlich der ATW werden soll- 
te. 

Der Rechner wurde erstmals auf der 
COMDEX im November 1987 unter dem 
Namen ABAQ vorgestellt. Damals wurden 
zwei Versionen gezeigt: Eine war eine Kar- 
te, die an den MegaST Bus angeschlossen 
wurde. Die zweite Version war ein eigen- 
ständiges Tower-System, das einen mini- 
aturisierten MegaST enthielt. Die Version 
externe Karte wurde irgendwann während 
der Entwicklung fallen gelassen. Periheli- 
on erfuhr später, dass der Name "ABAQ" 
in Europa bereits für andere Produkte ge- 
bräuchlich war, und so wurde der Produkt- 
name in ATW-800 geändert. 


Die Hardware 


Das ATW-System steckt in einem großen 
Tower-Gehäuse und besteht aus drei 
Hauptbestandteilen: 


der Hauptplatine mit einem T800- 
20 Transputer und 4 MByte RAM, 
erweiterbar auf 16 MB, einem kom- 
pletten miniaturisierten MegaST ST 
als E/A-Prozessor mit 512 kByte 
RAM 

das Blossom-Videosystem mit 

1 MByte Dual-Ported-RAM. 

Alle diese Teile werden über die 
20 Mbit/s-Prozessorverbindungen 
des Transputers verbunden. 


Die Hauptplatine enthält auch drei Steck- 
plätze für zusätzliche sogenannte Farm- 
karten mit jeweils vier Transputern. Damit 
besteht ein voll ausgebauter ATW aus 13 
Transputern. Der Bus ist auch extern ver- 
fügbar, mehrere ATWs lassen sich zu einer 
großen Farm verbinden. Die Hauptplatine 
besitzt einen separaten Steckplatz für ei- 


nen der INMOS-Crossbar-Switches, um die 
Leistung des Netzwerks zwischen den 
Chips zu verbessern. 


Das Betriebssystem 


Ein Computer ohne Betriebssystem ist 
gänzlich nutzlos. Die ATW-800 nutzt als Be- 
triebssystem eine besondere Entwicklung 
von Perihelion namens HeliOS. HeliOS ist 
Unix-ähnlich, aber nicht Unix — so fehlt un- 
ter anderem ein Speicherschutz. Dies ist 
eine Konsequenz aus dem Fehlen einer 
MMU auf dem Transputer selbst. Die Kon- 
sequenzen sind nicht ganz so problema- 
tisch wie zu vermuten wäre. Anwendungen 
unter HeliOS laufen durchaus stabil. Die 
Stack-basierte Architektur des Transputers 
macht eine MMU nämlich weniger wichtig. 
Andererseits ist HelißOS Unix-ähnlich ge- 
nug, um Standard-Unix-Dienstprogramme 
auszuführen, einschließlich des X Window 
Systems für eine grafische Benutzerober- 
fläche (GUI). Außerdem lief HeliOS auf al- 
len Transputern in einer Farm "zur gleichen 
Zeit", so dass alle Rechenaufgaben voll- 
ständig verteilt werden konnten. Das Aus- 
schalten eines ATW hatte keine Auswir- 
kungen auf die gesamte Farm, die Auf- 
gaben wurden einfach auf andere Prozes- 
soren anderer Systemen verlagert. Später 
wurde HeliOS auf andere Prozessoren por- 
tiert, einschließlich der ARM-Architektur. 


Video 


Das Blossom-Videosystem wurde spezi- 
ell für den ATW entwickelt. Es bietet 4 ver- 
schiedene Videomodi mit bis zu 1280 x 960 
Pixeln bei 16 von 4096 Farben. Das Blos- 
som umfasst auch eine Reihe von Hoch- 
geschwindigkeitseffekten (128 Megapixel/s 
Füllrate) und Blitter-Funktionalität. Dies 
schließt auch die Möglichkeit ein, bis zu 
vier Masken auf eine Bit-Blit-Operation an- 
zuwenden. Dies ähnelt der Fähigkeit eines 
modernen Grafikprozessors, mehrere Tex- 
turen auf ein 3D-Objekt anzuwenden. Das 
für die Blossom zuständige Team arbeite- 
te später an einem anderen Atari-Projekt, 
der Videospielkonsole Atari Jaguar. 


Die verschiedenen Transputer von Inmos 


Modell Taktfrequenz Wordbreite 


M212 17.5, 20 MHz 16 bit 


16 bit 
20, 25, 30 Mhz 32 bit 


20, 25 MHz 32 bit 


Hinweise 


Mit on-board Disk Controller 


Preis und Leistung 


5.000 GBP im Jahr 1990 entsprachen 
damals etwa 13.700 DM oder 8000 US-$. 
Das entspricht heute etwa 9.900 GBP oder 
14.000 US-$. Zum Vergleich: Ein Atari TT 
kostete 1990 auch bereits 3.000 US-$. 

Wie schneidet die ATW-800 nun im Ver- 
gleich zu anderen Atari-Computern in Be- 
zug auf die Geschwindigkeit ab? Die 
Tabelle hierzu vergleicht die MIPS-Leistung 
mit anderen Atari-Computern. Es ließe sich 
argumentieren, dass der DSP im Falcon 
starke 16 MIPS Leistung bringt und somit 
CPU und DSP zusammen mit 20 MIPS 
mehr Power bringen als die kombinierten 
11 MIPS des ATW. Aber erstens ist ein DSP 
kein Allzweckprozessor, diese Leistung 
steht nicht für jedes Programm zur Verfü- 
gung. Zweitens lassen sich bis zu 12 wei- 
tere T800-20 in einen ATW einbauen - die 
Performance läge also deutlich über allen 
anderen Atari-Systemen. Das macht die 
ATW-800 zum schnellsten Computer von 
Atari, wenngleich nicht zum schnellsten 
TOS-Rechner. 


Kleinserie 


Ein besonderer Markterfolg war die ATW- 
800-Workstation dennoch nicht. Ein Ge- 
rücht besagt, dass nur zwischen 200 und 
350 ATWs gebaut wurden. Davon sollen 50 
bis 100 Geräte als Prototypen bereits im 
Mai 1988 auf den Markt gekommen sein. 
Die Produktionsserie wurde erst im Mai 
1989 freigegeben. Ein anderes Gerücht be- 
sagt, dass 200 ATWs an Kodak verkauft 
wurden. Auch an der Technischen Univer- 
sität Braunschweig sowie bei Volkswagen 
in Wolfsburg soll die ATW genutzt worden 
sein, unter anderem für Fahrwerksimula- 
tionen. Auf dem Etikett an der Rückseite 
eines ATW steht etwas wie Serial Number: 
AB84A 90XXXX. Die Seriennummern, die 
dem Autor bekannt sind, lauten 909131 und 
909215. Das Etikett bezeichnet die ATW 
auch als „Made in Gemany“. Das klingt un- 
gewöhnlich, hat aber einen Grund: Die Pro- 
totypen der ATW wurden noch in England 
bei Perihelion gefertigt. Die Fertigung der 
Serienmodelle sollte dann im Atari Compu- 


Die Preise der ATW in Großbritanien 


Preis in GBP 
Liste für Bildungs- 


einrichtungen 


+4MB RAM 750,- 


ter GmbH Technologiezentrum in der Juli- 
us-Konegen-Straße 24 in Braunschweig 
erfolgen. 

Was hat nun dem ATW-800 den Markt- 
erfolg verwehrt? Für das Scheitern dieser 
Maschine sind mehrere Aspekte verant- 
wortlich: 


Das Gerät war viel zu teuer für 
den Massenmarkt. Atari scheint 
nicht viel Zeit und Mühe in die Un- 
terstützung dieses Modells oder in 
die Entwicklung von Nachfolgern in- 
vestiert zu haben. Leicht vorstellbar 
ist auch, dass Atari mit jedem Ge- 
rät Verluste eingefahren hat 
HeliOS war eine zu exotische Um- 
gebung 
Perihelion blieb der exklusive Ver- 
triebspartner in England und war 
immer ein kleines Unternehmen mit 
geringem Werbe- und Entwick- 
lungsetat. Vielleicht waren auch 
Schwierigkeiten zwischen Periheli- 
on und Atari nicht unschuldig an der 
frühen Einstellung der ATW. 
Transputer als Technologie schei- 
terten schließlich, weil sie Proble- 
me bei der Preisgestaltung und 
später bei der Leistung im Vergleich 
zur (traditionellen) Konkurrenz hat- 
ten 
Inmos als einziger Hersteller die- 
ser CPUs war ein zu kleines Unter- 
nehmen. Im Jahr der Veröffentli- 
chung der ATW musste Inmos 
Insolvenz anmelden. 


Geschwindigkeiten im Vergleich 


Modell Takt 


Falcon 


ATW 


64 bit Fließkommaeinheit 


20, 25, 30 Mhz 32 bit 


64 bit Fließkommaeinheit 


CPU 
ST 8MHz 68000 


16MHz 68030 3.84 MIPS (Motorola DSP: 16 MIPS) 


20MHz T800-20 10 MIPS (je T800, also 130 MIPS für 


MIPS 
1 MIPS 


Jahr 
1985 


1992 


1989 


13 x T800-20) 


Titelthema Workstations 


Was bleibt 


Trotz des Scheiterns der Maschine für 
die breite Masse ist die ATW-800 ein guter 
Computer. Er hatte das Potenzial, in eini- 
gen Nischen wie dem wissenschaftlichen 
Rechnen vorteilhaft eingesetzt zu werden. 
Die Software dazu musste selbst geschrie- 
ben werden, für Forschung und Entwick- 
lung kein ungewöhnlicher Vorgang. Nutzen 
Sie die Gelegenheit, sollte Ihnen jemals ei- 
ne solche Rarität über den Weg laufen. (gb) 


Links 


http://en.wikipedia.org/wiki/ 
Atari_Transputer_Workstation 
http://www.old-computers.com/museum/ 
computer.asp?st=1&c=33 
http:/en.wikipedia.org/wiki/HelißS 
http://www.classiccmp.org/ 
transputer/rtu_atw800.htm 

http://www. classiccmp.org/ 
transputer/atw800.htm 
http://www.atarimuseum.com/ 
computers/16bits/Transputer.html 
http://www.atari-computermuseum.de/ 
atw800.htm 


Danke an Fritz Hohl für die Überlassung 
seines Blogeintrags zur ATW-800, der Vorlage 
dieses Artikel war. 


Technische Daten 
CPU: 

Inmos T800-20 @20 MHz (10 MIPS) 
RAM: 

4 MByte (expandable to 16MB) 
HDD: 

44 MByte 
Betriebssystem: 

HeliOS 
Grafik: 


Blossom Video System mit 1 MByte Dual-ported-RAM, 
mit folgenden Modi 
Modus 0: 1280 x 960 Pixel, 16 Farben aus einer 
Palette von 4096 (entspricht 16 echte Graustufen 
auf einem Monochrommonitor) 
Modus 1: 1024 x 768 Pixel, 256 Farben aus einer 
Palette von 16,7 Millionen 
Modus 2: 640 x 480 Pixel (2 virtuelle Bild- 
schirme), 256 Farben aus einer Palette von 16,7 
Millionen 


Modus 3: 512 x 480 Pixel, 16,7 Millionen 


Interfaces: 
RGB Component Display Interface 


Enthält einen miniaturisierten MegaST mit 512 kByte 
RAM und allen seinen Interfaces 
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) Verein zum Erhalt klassischer Computer e.V. 
Foren-Higyhlignts 


Besonders interessante Diskussionen auf https:/lforum.classic-computing.de 


UNIX Geschichte 


Foren-User ThoralAsmussen hat sich die Mühe gemacht, 
viele Fakten und noch mehr Links zur 
Entwicklungsgeschichte von UNIX zusammenzutragen. 
Neben einer Vorstellung der Hardware, auf der die erste 
UNIX Version entwickelt wurde, stellt der Beitrag auch 
wichtige Entwickler, Meilensteine der Entwicklung und 
einige Legenden rund um das Betriebssystem vor. 
https://forum.classic-computing.de/ 
forum/index.php?thread/26082-unix-was- 
ist-das-woher-kommt-das/ 


Junior Computer 


Der Junior-Computer war ein erweiterungsfähiger 
Einplatinencomputer-Bausatz auf Basis des 6502- 
Prozessors. Entwickelt wurde der Rechner von Loys 
Nachtmann für die Zeitschrift Elektor, die den Bausatz in 
einer mehrteiligen Artikelserie ab Mai 1980 vorstellte. 
Forenuser 2ee hat nach 40 Jahren die Kopien dieser 
Artikel wiedergefunden und sich daran gemacht, den 
Einplatinen-Computer neu aufzubauen. Dabei hat er 
gleich mehrere Verbesserungen gegenüber dem 
Originalentwurf eingebaut. 
https://forum.classic-computing.de/f 
orum/index.php?thread/ 
26311-junior-computer 


Beliebte Programmiersprachen 


Ausgehend von einem Videoclip bei Youtube entwickelte 
sich eine umfangreiche Diskussion über verschiedene 
Programmiersprachen, ihre Beliebtheit und die Vor- und 
Nachteile. 
https://forum.classic-computing.de/ 
forum/index.php?thread/26338- 
beliebteste-programmiersprachen-1965- 
2019 


Forth 


An der Programmiersprache Forth scheiden sich die 
Geister. Die einen lieben den kurzen und effizienten 
Code, die anderen lehnen Forth gerade darum ab. Eine 
Diskussion zu Forth auf verschiedenen Rechnern geht 
ausführlich auf diese Fragen ein. 
https:/forum.classic-computing.de/ 
forum/index.php?thread/ 
26167-forth-diskussion-und-infos 


0S-9 

OS-9 ist ein Unix-ähnliches Echtzeit-, Multiuser-, 
Multitasking-Betriebssystem, das ursprünglich in den 
1980er Jahren von Microware Software für den 8-Bit- 
Prozessor 6809 von Motorola entwickelt wurde. Weitere 
Verbreitung erfuhr das System durch die Portierung auf 
die Motorola 68k-Architektur. Es gibt eine OS-9 Portierung 
auf den Atari ST, dessen Installation einige Tücken hat. 
Dazu hat sich eine sehr informative Diskussion 
entsponnen, die besonders auf das Kopieren der 
Diskettenimages auf echte Disketten eingeht. 


https://forum.classic- 
computing.de/forum/index.php ?thread/26 
335-atari-st-os-9-68k-boot-failure 


Apple I Seriennummern 


Der Apple-1 war der erste Computer, den die junge Firma 
1976 herstellte. Insgesamt wurden nur 300 dieser 
Einplatinenrechner gebaut, alle liebevoll in Handarbeit 
gefertigt. Auf einigen Apple-1 der ersten Serie findet sich 
eine handgeschriebene Seriennummer. 45 Jahre lang war 
nicht bekannt, wer der beiden Gründer und ihrer 
Mitarbeiter sie geschrieben hat - bis jetzt. Nach 
jahrelangem Sammeln von Schriftproben und unzähligen 
Befragungen brachte unser Vereinsmitglied Achim Baque 
schließlich mit zwei forensische Untersuchungen durch 
die rennomierten Authentisierungsexperen des 
Unternehmens Professional Sports Authenticator (PSA) 
endlich Licht in das Dunkel. Die Nummern zeigen 
eindeutig die Handschrift von Steve Jobs! 
https:/forum.classic-computing.de/ 
forum/index.php?thread/26706-autor-der- 
handgeschriebene-seriennnummern-auf- 
apple-1-eindeutig-gefunden/ 
https://www.apple Tregistry.com/en/ 
serial.html 


Mein liebstes Sammlerstück 


Taschenrechner von Texas Instruments 


TI voyage 200 


voyage 200 


Angeregt durch die Beschäftigung mit 
einem Texas Instruments TI-84 Plus 
schaute ich mich nach weiteren günstigen 
Angeboten zu TI-Taschenrechner um. 


ie auf den nächsten Seiten noch ausführlich darge- 

stellt wird, hatte der TI- 84plus einige Überraschun- 

gen parat: Er beinhaltet eine Z80-CPU, lässt sich 
programmieren und wird dazu noch günstig auf Kleinanzeigen- 
Seiten angeboten. Auch der TI voyage 200 ist ein solches Schnäpp- 
chen. Er ist oft schon für etwa 15€ zu bekommen. Solange er ein- 
wandfrei funktioniert und das USB Datenkabel beiliegt, lohnt sich 
auch hier der Kauf. 

Im TI voyage 200 werkelt eine alte bekannte CPU, nämlich die 
gute alte 32-Bit-CPU Motorola 68000. Sie treibt in anderer Bau- 
form auch den Commodore AMIGA, den Atari ST und viele weite- 
re klassische Computer an. Der TI voyage 200 gehört damit zur 
sogenannten TI-68k-Gruppe. Dazu gehören auch der TI- 
92(I1)(Plus) und der TI-89(Titanium). 

Spannend wird das kleine Gerät durch seine Programmierbar- 
keit in der Hochsprache C und durch eine Portierung der GNU 
Compiler Collection. TiGCC ist eine vollständige Entwicklungsum- 
gebung für die Programmierung des kleinen Rechners. Damit nicht 
genug - mit dem TiEMU steht ein Emulator bereit, der unter Mi- 
crosoft Windows läuft und das Testen während der Programment- 
wicklung deutlich erleichtert. Die Installation und Nutzung von 
TIGCC und TiEmu unter Windows werden auf den Webseiten von 
Andre Gassen gut beschrieben. Es muss übrigens kein natives 
Windows sein: Eine virtuelle Maschine mit Windows XP beispiels- 
weise auf einem Apple Macintosh mit OS X Catalina tut es auch. 
Der Transfer von Programmen auf den Rechner passiert wie beim 
TI-84 plus mit TI-Connect und ist auf der nächsten Seite beschrie- 
ben. Als Ausgangspunkt für eigene Experimente eignen sich die 


Beispielprogramme von der TiGCC-Seite. In der Sprache C zu 
programmieren ist komfortabel und es gibt viele kleinere C-Sour- 
cen, die sich relativ einfach Portieren lassen. Dabei hilft das Tu- 
torial von den Technoplaza-Seiten. Wem C als Programmier- 
sprache zu langweilig ist, kann übrigens auch in Assembler 
arbeiten. Auch hierzu liefert Technoplaza das passende Tutorial. 
Und natürlich gibt es viele, fertige Programme in Assembler oder 
BASIC. 

Und sollte einmal das Display defekt sein, so finden sich bei 
Youtube passende Reparaturanleitungen. Die nötigen Kenntnis- 
se und Fertigkeiten vorausgesetzt, lässt sich auch ein kaputter Ti 
voyage 200 wieder zum Leben erwecken. 


Links: 


Übersicht zur TI-68k-Gruppe: 
http://www.datamath.org/Architecture.htm#M68k-Mask 
TIGCC: 

http:/tigec.ticalc.org/ 

Beispielprogramme: 
http./tigec.ticalc.org/examples.html 

TIEMU: 

http://Ipg.ticalc.org/prj_tiemu/index.html 

Seiten von Andre Gasser 
https://blog.andregasser.net/how-to-develop-ti-voyage-200- 
programs-on-windows-7-64-bit-using-tigcc/ 
C-Tutorial: 
http://www.technoplaza.net/programming/ 
Assembler-Tutorial: 
http://www.technoplaza.net/iassembly/lessonT1.php 
Basic Programme: 
https://www.ticalc.org/pub/v200/basic/programs/ 
Assembler Programme: 
https://www.ticalc.org/pub/v200/asm/ 

Display reparieren: 
https://www.youtube.com/watch?v=u74etmyXraO 


6 TISCC IDE + hello, E 


Ele Edit Find Project Debug Tools He 
D-B-8 3|x 3 R8]l2=2JaRa- m SA m 


„lolxi 


hello 17 € Source File 
U Header Fies 1H Created 17.11.2021; 12:15:45 
3-09 CFies 
B he #include <tigeclib .h> 
O9 GNU Assembly Files 
0 ASßk AssembbyFies |void _main (void ) [ 
I Otiect Files I clear the screen 
I Archive Fles CirScr 0: 
I TertFies 
I Dies Files 


1 print the string at the top left co 
DrawStr (0, 0, "Hello, World” 


II wait for a key press before the pro 
N 0; 


M_—_— ——— nn ——] 
Arie Toll. tinCategoy 1 161 1 [01 Character; |CATIGELNPigjectsNhelloe 


Windows XP VM mit TiGCC IDE und „Hello World“ plus TIEMU 


Mein liebstes Sammlerstück 


Texas Instruments 
T1-84 plus 


Is Sammler lohnt es sich, hier und 
da Gebrauchtmärkte zu be- 
suchen. Mein TI-84 plus fand sich 
in einem sozialen Kaufhaus zum Spott- 
preis von 2 EUR. Eigentlich wollte ich kein- 
en Taschenrechner kaufen — aber an- 
gesichts des Preises konnte ich nicht wider- 
stehen. Die Funktionstüchtigkeit ließ sich 
vor Ort nicht testen, da die Batterien fehl- 
ten. So verschwand er erst einmal für ein- 
ige Wochen in einer Schublade. Als dann 
endlich einmal vier AAA-Batterien zur Hand 
waren, zeigte sich das Gerät in einem er- 
sten Test als voll funktionsfähig. 
Es folgte meine Lieblingsbeschäftigung 
— die Suche von Informationen zum Gerät 
im Internet. Das Handbuch war schnell ge- 
funden, ebenso einige andere nützliche In- 
formationen. Zu diesen zählt der Hinweis, 
dass sich das Gerät mit Tl-Connect mit 
einem PC oder Macintosh verbinden kann. 
Also wurde flugs TI-Connect für Macintosh 
installiert und siehe da: Das Gerät wurde 
sofort gefunden und war über ein Stan- 
dard-USB-Kabel angebunden. 


Die Infos aus dem Internet zeigten wei- 
tere sehr interessante Dinge. Der Taschen- 
rechner ist als mathematischer Rechner 
konzipiert und verfügt über ein grafik- 
fähiges Display mit 8 Zeilen und je 16 
Zeichen oder 64 x 96 Pixeln. Dem Arbeits- 
speicher von 24 KByte sind 480 KByte 
Flash-Speicher beigestellt, dort ist Platz für 
bis zu 30 Apps für Spezialfunktionen. Im 
Inneren des TI-84 plus werkelt die gute, 
alte Zilog Z80- CPU. Sie lässt sich selbst 
programmieren in TI-Basic und Z80 Assem- 
bler. Es gibt bereits eine Vielzahl von ferti- 
gen Programmen zum Download. Das 
Gerät wird heute noch als Neuware ver- 
kauft und kommt in Schulen zur Anwen- 
dung. Ein bekannter Internethändler ver- 
langt für das Neugerät immerhin 133 EUR, 
in Online-Kleinanzeigen finden sich eine 
Vielzahl von Angeboten schon ab 15 €. Ein 
Schnäppchen war das kleine Ding damit 
aber immer noch. 

Das TI-BASIC ist ein sehr spezielles 
BASIC, das Texas Instruments für neuere 
Taschenrechner verwendet und für jede 


Technische Daten 


Anzeige mit 8 Zeilen mit je 16 Zeichen, 64 x 96 
Pixel monochrom 


__.,24 KByte RAM 

____,1 MByte Flash ROM, 480 KByte verfügbar 
_____,Z80-CPU mit 15 MHz 

____Echtzeituhr 

—_——, USB-Schnittstelle 


Stromversorgung mit 4 x AA und Knopfzelle 
SR44 


Die TI-84 SilverPlus Edition besitzt 1 MB Flash-ROM 
und ein Farbdisplay mit 65.535 Farben. 


Modellreihe anpasst. Die Version des TI- 
84 plus kennt beispielsweise komplexe 
Zahlen und Matrizen als Variablentypen. 
Das eigentlich Wertvolle am BASIC sind 
die vielen, im Internet zu findenden Pro- 
gramme. Neben Programmen für den 
Mathematik-, Physik- und Biologieunter- 
richt gibt es auch Spiele und anderes. 
Ein einfaches Beispiel (smile.8xp): 


Axesoff 

Lbl A 
cCircle(0,0,5) 
Line(-2,-1,2,-1) 
Line (-2,-1,-2.5,0) 
Line(2,-1,2.5,0) 
PeEzOn (2, 25)) 
PeEzZON27225)) 
Tineld,s, 1,2) 
Line (0,5,2,6) 
eirelei,2 3,1 
eıweulea((2,2,.B8,A) 
eirelei(07.10,07218) 
ClrDraw 

Goto A 


) 


Dieser BASIC-Code zaubert ein Smiley 
auf das Display (siehe nächste Seite). 

Spannender als BASIC ist natürlich die 
Programmierung in Z80-Assembler. Der 
Taschenrechner selbst kann Programme 
in Maschinensprache starten, aber Assem- 
bler-Quellcode nicht selbst übersetzen. 
Dazu braucht es einen Z80-Assembler — 
ich nutze fasm in einer virtuellen Maschine 
mit Windows XP und dort in der DOS Box. 
Die fertig übersetzten Programme wandern 
dann mit TI-Connect auf den angeschlos- 
senen Taschenrechner. 

Auch für die Assemblerprogrammierung 
existieren zahlreiche Beispielprogramme. 
Um zu lernen, wie mit den spezifischen 
Funktionen und Includes in TI-Assembler 
gearbeitet wird, eignet sich das Tutorial von 
Sean McLaughlin. Das Tutorial richtet sich 
eigentlich an Nutzer des Vorgängermo- 
dells TI-83, da aber der TI-84 plus zu 
seinem Vater voll kompatibel ist, lassen sich 
die Lerninhalte fast 1:1 übertragen. Manch- 
mal tauchen kleinere Unstimmigkeiten auf; 
so definiert die woanders heruntergeladene 
Include-Datei ti83plus.inc für das Beispiel- 
programm Hello.Z80 den Funktionsnamen 
bcall und nicht wie im Tutorial beschrieben 
den Namen b_call. 


T284 Plus 
#3 Texas INSTRUMENTS 


Ausgabe des BASIC-Programms smile.8xp 


Auch hierzu ein Beispiel (hello.z80): 


„noliee 
ameludenutasspliusennei 
#define ProgStart $9D95 
‚list 

MORg) Proegstants 2 

db t2ByteTok, tAsmCmp 
beall\ CeIrLeDEe IT) 

All al, 0) 

ill (CurRow), hl 


ld hl, msqg 

bcall(_PutS) ;Display the text 
bcall (_NewLine) 

bcall (_GetKey) ; Wait for a key 
ret 

msg: 

seh nauliker yore U, W 

„end 

„end 


Assembliert wird das Programm mit der 
asm.bat Datei unter DOS: 


@echo off 

echo ==== Now assembling %1.z80 
for the TI-83 Plus ==== 

taen 80 -1 6 
c:\asm\source\%1.z80 
c:\asm\exec\%1.bin 

if errorlevel 1 goto ERRORS 

rem This is necessary because of a 
DevPac8x bug 

cd c:\asm\exec 
c:\asm\tasm\devpac8x %1 

cd c:\asm\tasm 


echo ==== Job finished. Program 
saved as %1.8xp ==== 

goto DONE 

:ERRORS 

echo ==== Errors!!! ==== 

: DONE 

del c:\asm\source\%l1.1st > NUL 
del c:\asm\exec\%1l.bin > NUL 
echo ==== Done ==== 


Der Start von ASM-Programmen klappt 
mit der Tastenfolge 2nd — Catalog — Aus- 
wahl asm( - Enter - PRGM - Auswahl ASM 
— Enter. Die Ausgabe bringt wie erwartet 
ein "Hello world!" auf das Display. 


Ausgabe des Assembler-Programms hello.z80 


— u u 
TF-84 Pius 
#3 Texas InsTRUMENTS 


MirageOS wird von manchen Spielen benötigt 


Mit dem TI View Screen und dem TI Presenter können die Ausgaben des Taschenrechners auf 
einen Overhead-Projektor gebracht werden. 


Sean McLaughlins Assembler Tutorial 
https://tutorials.eeems.ca/ 
ASMin28Days/welcome.html 

Weitere Assembler-Programme: 
https://wwu.ti- 
calc.org/pub/33plus/asm/programs/ 
http://www.benryves.com/ti83plus.htm 
MirageOS: 

https://www.ti- 
calc.org/pub/83plus/asm/games/ 
mirageos/rate.html 


Es lohnt sich, die zahlreichen Beispiel- 
programme aus dem Internet auszupro- 
bieren. Einige Spiele setzen ein Betriebs- 
system-Addon voraus, zum Beispiel das 
MirageOS. Es lässt sich wie andere Apps 
installieren und ist danach unter APPS zu 
finden und zu starten. 

Insgesamt bietet das Gerät deutlich 
mehr, als am Anfang zu erwarten war. Es 
bietet viel Spaß und eignet sich sowohl als 
Taschenrechner, als kleine Spielekonsole 
und auch als Programmierplattform — und 5 
das alles für 2 EUR (ps). 


Der TI-Assembler findet 
mi, sich auf der Heft-CD 


Links 


http://www.datamath.org/ 
Architecture.htm#Z80-Flash 
TI-BASIC 
https://de.wikipedia.org/wiki/TI-Basic 
TI-Basic Beispiel 
https://thorben.voss.art/articles/gtr/ 
gtr_ti-84.php 

Tl-Assembler 
https://wwn.ticalc.org/archives/files/ 
fileinfo/15/1504.html 


Bild von Jörg Wörner http://www.datamath.org, Nachdruck mit freundlicher Genehmigung. 
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Das serielle Netzwerk von Sinclair Spectrum und QL 


QLAN entschlüsselt 


Sinclair Spectrum und Sinclair QL verfügen über eine 
einfache Möglichkeit der Vernetzung. Ein einfaches 
Audiokabel zwischen den Geräten genügt als Hardware. 
Alles andere bringen die pfiffigen Briten bereits von Haus 


aus mit. 


ieser Artikel richtet sich an alle 

QL-Benutzer, die ihre QLs oder 

kompatiblen Rechner über die 
eingebaute Netzwerkfunktion (QNET) 
miteinander verbinden möchten. Die Ver- 
bindung kann zum Austausch von Dateien 
dienen oder dazu, das Potenzial für Multi- 
User-Spiele zu erforschen. Vielleicht faszi- 
niert aber auch schlicht nur die einfache, 
aber überraschend effektive Netzwerktech- 
nologie. Der Artikel liefert auch Material, 
das denjenigen helfen soll, die ihren ZX 
Spectrum an das QL-Netzwerk anschlies- 
sen wollen. 

Während meiner mehrjährigen Beschäf- 
tigung mit QNET und dem zugrundelie- 
genden Protokoll — im Folgenden als 
"QLAN" bezeichnet - habe ich die Einfach- 
heit und Eleganz des Designs schätzen 
gelernt. Ich möchte den Einfallsreichtum 
der ursprünglichen Entwickler, Sinclair und 
Tony Tebby, hervorheben. Ich möchte auch 
QView und insbesondere Lau Reeves für 
die akribische Kommentierung des 
Minerva-Quellcodes erwähnen. Diese ha- 
ben mein frühes Verständnis des Netz- 
werktreibers unterstützt, bevor ich mich 
dann daran machte, den erweiterten TK2- 
QLAN-Quellcode zu verstehen. 
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Es gibt bereits einige ausgezeichnete 
Ressourcen zur Beschreibung von QNET 
im Internet, insbesondere: 

Roy Wood/Q-Branch’s Super- 
BASIC/SBASIC Reference Manual 
Online — Kapitel 17 , ein Großteil 
davon wurde von Rich Mellor ver- 
fasst. 

ein Artikel mit dem Titel Network 
von David Denham wurde 
ursprünglich in QL Today veröffent- 
licht und ist auf der Website von 
Dilwyn Jones verfügbar 

das originale QL Benutzerhand- 
buch, verfügbar auf Dilwyn’s Seite 

Es ist unvermeidlich, dass sich in diesem 
Artikel bereits vorhandene Informationen 
teilweise wiederholen. Aber das Ziel war 
es, sich auf das zu konzentrieren, was noch 
nicht dokumentiert ist. Außerdem sollten 
Informationen verdeutlicht werden, die an 
anderer Stelle gefunden wurden. In einigen 
Fällen wurden Fehler in diesen Informa- 
tionen auch korrigiert. Die Hoffnung ist es, 
etwas von meiner eigenen Faszination in 
diesem Bereich mitzuteilen. Mit etwas 
Glück wird hier etwas Nützliches präsen- 
tiert, das Sie noch nicht gelesen haben. 
Vielleicht fördert der Artikel die Entwicklung 
neuer Ideen für das QL-Netzwerk. 


Der Stand der QLAN Entwick- 
lung 


Verbesserte Versionen der QLAN-Gerä- 
tetreiber wurden für verschiedene QL-Platt- 
formen entwickelt. Sie haben auch einige 
bisher nicht dokumentierte Fehler im Netz- 
werkcode des Spectrum/Interface-1 Sha- 
dow-ROM behoben. Mit diesen verbesser- 
ten Treibern war es möglich, das Netzwerk 
mit dem 4,5- bis 8-fachen der ursprüng- 
lichen Bitrate mit entsprechend schneller 
QL-ähnlicher Hardware (QL/SGC zu Q68 
bzw. Q68 zu Q68) zu betreiben. Der Autor 
ist gerade dabei, den grundlegenden QL- 
Treiber zu optimieren. Dies wird ihn auf et- 
wa das 1,5-fache seiner ursprünglichen 
Geschwindigkeit bringen. Mit geeigneten 
Änderungen an den Interface-1-ROM-Rou- 
tinen auf der Spectrum-Seite ist es endlich 
möglich, eine zuverlässige bidirektionale 
Kommunikation zwischen dem 7,5-MHZz- 
QL und einem Spectrum zu erreichen, wenn 
auch mit der ursprünglichen Netzwerk-Bit- 
rate. 

Dank des klaren Designs und der um- 
fangreichen Quellcode-Kommentare war 
es relativ einfach, den ursprünglichen TK2- 
Netzwerktreiber (für den S/GC) aus dem 
SMSQV/E-Quellbaum zu nehmen. Er ließ für 
den Q68 und seinen Hardware-Timer/ 
Counter neu entwickeln. Dadurch wurden 
die meisten Abhängigkeiten von den m68k- 
Befehlszyklus-Timings beseitigt. Diese be- 
stimmen das Design des ursprünglichen 
QLAN-Gerätetreibers und sind die Haupt- 
ursache für Kommunikationsprobleme zwi- 
schen verschiedenen QL-Maschinen. 
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Der ND-Q68-Treiber wurde im letzten 
Jahr über das Sinclair QL Forum und die 
Website von Dilwyn Jones der Communi- 
ty zur Verfügung gestellt. Es ist erfreulich 
zu sehen, wie die Anwender ihre Q68s im 
Netzwerk einsetzen. Eine aktualisierte Ver- 
sion des ND-Q68-Treibers wird Anfang 
nächsten Jahres zur Verfügung stehen. 
Ebenso werden die verbesserten Treiber 
für die Basisgeräte QL und SGC bereitge- 
stellt werden, sobald sie für die Öffentlich- 
keit verfügbar sind. 

Falls jemand an den Verbesserungen der 
Spectrum Interface-1-Netzwerkroutinen in- 
teressiert ist, könnten diese ebenfalls zur 
Verfügung gestellt werden. Es ist aber für 
die meisten Benutzer kein trivialer Prozess, 
das Interface-1 ShadowROM zu aktualisie- 
ren. 

Mein aktuelles und langjähriges Projekt 
ist der QLAN-zu-USB-Bridge-"QLUB'-Ad- 
apter. Mit diesem kann ein emulierter QL 
auf einem PC an das systemeigene QL- 
Netzwerk angeschlossen werden. Dazu 
wird eine eigene Firmware verwendet, die 
auf einem preiswerten Mikrocontroller läuft. 
Sie wird über den USB-Anschluss ange- 
schlossen. In Verbindung mit einer neuen 
QDOS-Software und einem leicht modifi- 
zierten QLAN-Gerätetreiber erleichtert sie 
den ansonsten mühsamen Datentransfer 
zwischen den beiden Plattformen deutlich. 


Einführung in das 
QL Netzwerk 


Es wird empfohlen, diesen Abschnitt in 
Verbindung mit dem SuperBasic/SBASIC- 
Referenzhandbuch zu lesen. Ich habe be- 
wusst Details weggelassen, die dort bereits 
gut dokumentiert sind. Nur diejenigen Pas- 
sagen wurden übernommen, die für den 
Kontext von Ergänzungen zum Thema er- 
forderlich sind. Es wurden auch einige klei- 
ne Fehler korrigiert, die in dieser ansonsten 
sehr umfassenden Quelle gefunden wur- 
den. 


QNET kompatible Systeme 


Zusätzlich zum Basis-QL, dem Aurora- 
QL-Mainboard-Ersatz, der QXL-PC-ISA- 
Karte und der neueren Q68-FPGA-basier- 
ten Maschine enthalten alle die meiste oder 
die gesamte QNET-Hardware, die für die 
Verbindung benötigt wird. Die Q68 erfor- 
dert einige zusätzliche Komponenten, die 
nachgerüstet werden müssen. Ein QL, der 
mit einer Gold- oder SuperGoldCard aus- 
gestattet ist, läuft natürlich bereits sehr gut 
mit QNET. Alle erforderlichen Protokoll-Ti- 
mings werden automatisch in der Software 
angepasst, um ihren schnelleren CPUs ge- 
recht zu werden. Die Thor-Maschinen ver- 
fügen auch über die erforderliche QNET- 


Hardware und -Software. 

Zusätzlich zu QL-kompatiblen Rechnern 
wird funktionsgleiche Hardware und das 
gleiche Basisprotokoll vom ZX Spectrum 
verwendet, wenn das Interface-1 eingebaut 
ist. Aber aufgrund einiger subtiler Fehler im 
Interface-1 Shadow ROM kann ein zuver- 
lässiger Empfang am QL vom Spectrum 
aus nur mit einer aktualisierten Interface- 
1-Firmware in Verbindung mit einem leicht 
optimierten QL NET-Treiber erfolgen. Das 
ist wirklich schade, denn viele Benutzer 
sind vom Spectrum auf den QL umgestie- 
gen. Sie hätten von der Verbindung der bei- 
den ansonsten inkompatiblen Geräte 
profitieren können, ohne auf die langsame- 
ren seriellen Schnittstellen zurückgreifen 
zu müssen. 

Andere potenzielle Kandidaten für eine 
Verbindung mit QNET sind die Q40/Q60 
und SAM Coupe. Aber diese Maschinen 
würden zusätzliche, wenngleich relativ ein- 
fache Hardware-Schnittstellen und die Ent- 
wicklung einer geeigneten Software 
erfordern. 


Typische Anwendungen 
für QNET 


Einfache Dateiübertragungen zwischen 
zwei oder mehreren Stationen sind mit dem 
QL-Basisnetz ohne die Erweiterungen von 
TK2 problemlos möglich. Auch ohne TK2 
kann QNET sinnvoll eingesetzt werden, 
beispielsweise für 

Boot-strapping": Übertragung von 
S/Basic-Erweiterungen und -An- 
wendungen auf einen nicht erwei- 
terten QL beim Start. 

Rettung laufender Arbeiten: Spei- 
chern von Dateien im Arbeitsspei- 
cher auf einem anderen 
funktionierenden QL, wenn Sie die 
lokalen Mikrolaufwerke nicht zur 
Mitarbeit bewegen können. 
"Spooling" von Druckdateien: Ver- 
wendung von COPY auf einem Ge- 
rät mit angeschlossenem Drucker, 
um eine Hardcopy zu erhalten. 

Multiplayer-Gaming: Streaming von 
Spieldaten in Echtzeit zwischen 
zwei oder mehr Rechnern und Spie- 
lern. 

Verknüpfung mit dem ZX Spectrum: 
Während Code- und BASIC-Datei- 
en nicht direkt zwischen QL und 
Spectrum kompatibel sind, kann 
sich die Erhaltung von Spectrum- 
Dateien auf der zuverlässigeren 
QL-Hardware als sehr nützlich er- 
weisen. 

Projekte mit elektronischen Schnitt- 
stellen: Mit einem entsprechend 
programmierten Mikrocontroller, 
der QLAN "spricht", ist es möglich, 


3,5mm Klinkenstecker Mono 


3,5mm Klinkenstecker Stereo 
Beide Stecker sind als Netzverbinder für 
QLAN geeignet. 


den QL mit Ihren elektronischen 
Steckbrett-Projekten zu verbinden. 
Sobald ein funktionierendes QNET ein- 
gerichtet ist, kann die Geschwindigkeit und 
die Zuverlässigkeit des Netzwerks unsere 
alternden MDVs tatsächlich übertreffen. 
Dies gilt, obwohl die rohe Bitrate des Netz- 
werks (ca. 89kbps) viel niedriger ist als die 
für Mikrolaufwerke (200kbps nom.). Das 
Ausführen großer Programme über das 
Netzwerk kann sich oft als zuverlässiger 
und schneller erweisen als das Laden von 
einer fehlerhaften Kassette. Dort sind oft 
mehrere Durchläufe des Bandes erforder- 
lich, um die Dateiblöcke korrekt zu lesen. 
In Anbetracht des interaktiven Charak- 
ters des NET-Geräts ist die Verwendung 
der NET-Basisfunktionalität nicht beson- 
ders praktisch, aber nichtsdestotrotz effek- 
tiv. Es ist erforderlich, dass Befehle auf 
beiden Peer-Stationen gleichzeitig erteilt 
werden, bevor die Dateiübertragung begin- 
nen kann. Wie wir später lesen werden, löst 
TK2 dieses Problem sehr effektiv mit sei- 
ner FSERVE-Dateiserver-Funktion. 


Stationen verbinden 


Jeder QL und mehrere seiner kompati- 
blen Hardware-Ersatzgeräte enthalten die 
grundlegende Hardware und Software, um 
die Verbindung untereinander zu erlauben. 
Dies ist mit einem einfachen zweiadrigen 
Kabel möglich, wie es für Mono-Audio-An- 
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wendungen verwendet wird. An beiden En- 
den müssen die Kabel mit einem 3,5-mm- 
Klinkenstecker besitzen. Es ist auch durch- 
aus möglich, eine 3-adrige Stereover- 
kabelung mit dem TRS-Stecker (Tip- Ring- 
Sleeve) zu verwenden. 

Jede Station ist mit der nächsten in einer 
Reihenschaltung verbunden. Dabei wer- 
den eine oder beide der beiden (identi- 
schen) NET-Buchsen verwendet, die un- 
auffällig hinten rechts am QL liegen. Die 
beiden Stationen an den äußersten Enden 
der Kette haben nur eine Buchse, während 
bei jeder weiteren Station beide belegt sind. 

In der häufigsten Situation mit nur zwei 
angeschlossenen Stationen wird daher nur 
ein einziges 2-adriges Kabel benötigt. An 
jeder Station eine NET-Buchse bleibt frei. 
Es spielt keine Rolle, welche der beiden 
verfügbaren Buchsen an beiden Enden ver- 
wendet wird. Es ist Teil des QNET-Hard- 
waredesigns, die beiden Endstationen mit 
einer einzigen unbelegten Buchse zu be- 
lassen. Die Buchsen selbst sind geschal- 
tet: Jede nicht angeschlossene Buchse 
besitzt einen Pull-Down Widerstand als Ter- 
minator für die NET-Leitung. Sobald ein 
Klinkenstecker eingesteckt ist, wird der Ter- 
minator an dieser Buchse effektiv deakti- 
viert. Die Bildung einer "Schleife" mit zwei 
miteinander verbundenen Endstationen 
führt zu schlechtem Empfang. Aufgrund von 
Signalreflexionen wird das Netz höchst- 
wahrscheinlich unbrauchbar. 

Die Einfachheit, leichte Verfügbarkeit, 
Flexibilität und Robustheit der erforderli- 
chen Verkabelung ist nach Ansicht des Au- 
tors ein wesentlicher Vorteil des QNET- 
Konzepts gegenüber z.B. einer herkömm- 
lichen RS-232/COM-Port-Lösung. Die ma- 
ximale Gesamtlänge der Kabelstrecke wird 
mit 100 m angegeben (QL-Benutzerhand- 
buch, S.34). Der Autor hat in der Praxis mit 
handelsüblichen und preiswerten Mono- 
und Stereo-Audiokabeln erfolgreich Kabel- 
strecken von 30 m und mehr verwendet. 


Grundlegende 
Netzwerknutzung 


Der in QDOS eingebaute grundlegende 
NET-Gerätetreiber ermöglicht eine einfa- 
che Peer-to-Peer-Übertragung von Datei- 
en. Dies passiert unter Verwendung bekan- 
nter S/Basic-Befehle wie COPY und LOAD, 
LBYTES, EXEC (mit ihren SAVE-Gegen- 
stücken). Außerdem ist das Senden und 
Empfangen beliebiger Byteströme unter 
Verwendung expliziter OPEN/PRINT- und 
OPEN/INPUT/INKEY$-Befehlsfolgen an 
den jeweiligen Enden der Verbindung mög- 
lich. 

Jeder Station wird mit Hilfe des S/Basic 
NET-Befehls eine eindeutige "Stations-ID" 
zwischen 1 und 63 (oder 64, je nach Ver- 
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Die Signalverfolgung zeigt die Lücken in der Paketübertragung. 


sion/ Alter des Treibers) zugewiesen. Eine 
Dateiübertragung wird durch die Eingabe 
gegenseitiger Befehle (Laden/Speichern) 
an jeder Station eingeleitet. Wenn nur zwei 
Maschinen miteinander verbunden sind, ist 
es möglich, erfolgreich zu kommunizieren, 
ohne die Stations-ID von ihrem Standard- 
wert "1" zu ändern. Eine Mehrdeutigkeit 
wird dadurch vermieden, dass auf jeder 
Station zu einem bestimmten Zeitpunkt nur 
eine Aktivität (Senden oder Empfangen) 
stattfinden kann. Dennoch wird auch in die- 
ser Situation empfohlen, eindeutige IDs zu 
vergeben. Neben der expliziten Angabe der 
Stations-ID der Gegenstelle beim Öffnen 
eines Kanals erkennt das NET-Gerät auch 
eine Stations-ID von O (Null) sowohl für den 
Eingang als auch für den Ausgang. Dies 
wird als "Netzwerk-Broadcast" bezeichnet. 
Außerdem kennt das NET Gerät die Mög- 
lichkeit "receive from any station", wobei 
die empfangende Station NET-Kanäle mit 
ihrer eigenen Stations-ID öffnet. 

Das grundlegende QLAN-Protokoll er- 
kennt End-of-File (EOF) Bedingung. Sie 
bestimmt, wann durch einen einem expli- 
ziten OPEN erstellte Bytestream-Verbin- 
dungen geschlossen werden sollen. Der 
NET-Treiber kennzeichnet das letzte Paket 
als solches, wenn der Ausgangskanal CLO- 
SEd ist. Dies kommt der "byte-seriellen" 
Kommunikation entgegen. Diese Methode 
ist jedoch unzureichend für Dateitransfer- 
verbindungen, die mit SAVE/SBYTES/ 
SEXEC eingeleitet und mit LOAD usw. 
empfangen werden. Bei diesen muss die 
empfangende Station von vornherein die 
erwartete Dateilänge und den Dateityp ken- 
nen. Um dem Rechnung zu tragen, stellen 
die Dateiübertragungsbefehle (Speichern 
usw.) dem allerersten gesendeten Paket 
einen 15 Byte langen "einfachen Dateikopf" 
voran. Er gibt die Anzahl der folgenden 
Bytes sowie andere Metadaten an, die von 
den LOAD/LBYTES/EXEC-Verfahren auf 
der Empfängerseite erwartet und interpre- 
tiert werden. Leser, die mit dem Tape-File- 
Header des ZX Spectrum und dem Äqui- 
valent für das Interface-1 vertraut sind, 
werden dies erkennen. 

Die NET-Verknüpfung kann auch jeder- 
zeit manuell abgebrochen werden, indem 


der Benutzer die Tastenkombination 
Strg+Leertaste drückt. Dadurch werden al- 
le impliziten Dateiübertragungskanäle in 
diesem Prozess geschlossen. Eine "EOF"- 
Bedingung wird gekennzeichnet und kann 
auf der Empfangsseite erkannt werden, 
wenn sie auf der Absenderstation abgebro- 
chen wird. Andererseits kann der Absen- 
der nicht wissen, ob der Benutzer an der 
Empfangsstation die Übertragung abge- 
brochen hat. Er wird stattdessen die Über- 
tragung des letzten Pakets so lange 
wiederholen, bis sie selbst manuell abge- 
brochen wird. 


Paketaufbau 


Es ist interessant zu verstehen, wie das 
QLAN-Protokoll dafür sorgt, dass die Roh- 
daten über die Verbindung fließen. Eben- 
so ist es interessant zu wissen, wie es die 
Zeit für andere Aktivitäten in der Maschine 
verwaltet und wie es die Netzzugangszeit 
mit anderen angeschlossenen Stationen 
teilt. 

Alle übertragenen Daten werden in "Blö- 
cke" oder Pakete von bis zu 255 Byte auf- 
geteilt, denen ein Paketkopf vorangestellt 
wird, gefolgt von dem eigentlichen Daten- 
paket. Bei einer Datei, die aus mehreren 
Blöcken besteht, haben alle Blöcke bis auf 
den letzten die volle Länge von 255 Bytes. 
Der letzte Block enthält die restlichen Bytes. 
Der Paketkopf enthält sowohl die IDs der 
Quell- und Zielstation als auch andere Me- 
tadaten, die vom Protokoll verwendet wer- 
den, einschließlich der aktuellen "Block- 
nummer" und Prüfsummen. 

Das Beispiel einer Signalverfolgung mit 
mehreren Paketen einer laufenden Über- 
tragung (Bild oben) zeigt die allgemeine 
Nutzung der Verbindung. 

Die sendende Station "lauscht" zunächst 
auf eine entsprechend lange Stille oder 
"Lücke". Sie zeigt an, dass die Verbindung 
frei ist, bevor sie ein "Scout"-Bitmuster auf 
die Leitung legt. Gleichzeitig liest sie den 
Verbindungsstatus zurück, um sicherzu- 
stellen, dass keine andere Station eben- 
falls versucht, die Verbindung zu bean- 
spruchen. Das Bitmuster, das für den Scout 
verwendet wird, wird sorgfältig berechnet, 
um sicherzustellen, dass verschiedene 


Sendestationen ein unterschiedliches Mus- 
ter erzeugen. Dies geschieht hauptsäch- 
lich auf der Grundlage ihrer eigenen, 
eindeutigen Stations-ID. Dies gewährleis- 
tet auch ein vorhersehbares Ergebnis — 
nämlich, dass alle Stationen außer der mit 
der niedrigsten Stations-ID den Konflikt er- 
kennen und sich zurückziehen. Die Sende- 
station mit der niedrigsten Stations-ID 
bemerkt den Konflikt nicht einmal und fährt 
mit ihrer Übertragung fort. 

Auf der Empfängerseite ignoriert die 
Empfangsstation den Verbindungsstatus 
vollständig, sobald der Beginn des Scouts 
erkannt wurde. Sie beginnt erst wieder, dar- 
auf zu achten, nachdem ein bestimmtes 
Zeitfenster verstrichen ist. Es dient dazu, 
die Scout-Phase zu überspringen, aber 
rechtzeitig auch, um den Beginn des dar- 
auf folgenden Paketkopfes zu erfassen. 
Nach der Übertragung des Headers wartet 
die sendende Station auf ein aktives "Ack- 
nowledge"-Signal (ein einzelnes Byte: 
0x01), bevor sie mit der Übertragung des 
eigentlichen Datenpakets beginnt. Dann 
wartet sie wiederum auf eine abschließen- 
de Bestätigung, um festzustellen, ob das 
Datenpaket erfolgreich empfangen wurde. 
Bei Erfolg wird die "Blocknummer" an je- 
dem Ende inkrementiert, so dass das 
nächste zu übertragende Paket bereit ist. 
Ein vertiefender Blick in den Signalverlauf 
während der Paketübertragung zeigt das 
Bild unten. 

Wenn die Lücke nicht erkannt wird, weil 
die Verbindung bereits in Gebrauch ist, 
bricht die sendende Station den aktuellen 
Übertragungszyklus ab. Sie verlässt sich 
dann darauf, dass der QDOS IOSS-Sche- 
duler die Übertragung später wieder auf- 
nimmt. Das passiert auch, wenn beim Sen- 
den des Scouts ein Konflikt festgestellt wird, 
weil eine andere Station gleichzeitig ver- 
sucht, die Verbindung zu beanspruchen. 


Ebenso verursacht ein nicht empfangenes 
Antwort-Byte — weil der Empfänger nicht 
zuhört oder das Paket aus irgendeinem 
Grund abgelehnt- den Abbruch des aktu- 
ellen Übertragungszyklus. In diesem Fall 
wird die aktuelle Blocknummer beibehal- 
ten. 

Die empfangende Station fragt die Ver- 
bindung regelmäßig ab. Sie bricht den ak- 
tuellen Abfragezyklus stillschweigend ab 
und sendet somit kein Antwortbyte, wenn 

sie den Scout nicht innerhalb eines 
definierten Zeitfensters erkennt 
sie feststellt, dass das Paket nicht 
für diese Station bestimmt ist oder 
von ihr erwartet wird 

oder sie eine beschädigte Prüfsum- 
me im Header oder im Datenpaket 
berechnet. 

Dann verlässt sich wie bei der Übertra- 
gung auf den QDOS IOSS-Scheduler, um 
den Paketempfang zu einem späteren Zeit- 
punkt erneut zu aktivieren. 

Der Empfänger passt seine "erwartete" 
Blocknummer in ähnlicher Weise wie der 
Sender an, je nach Erfolg oder Misserfolg. 
Auf diese Weise bleiben Sender und Emp- 
fänger synchron, indem sie sich auf die in- 
krementelle Blocknummer (0-65535) 
beziehen. Dadurch können alle wiederhol- 
ten Pakete (Block N-1) erkannt und beim 
Empfänger verworfen werden, während er 
weiterhin auf das erwartete Paket (Block 
N) wartet. Eine solche Situation kann ent- 
stehen, wenn die sendende Station das als 
Antwort auf das letzte gesendete Paket ge- 
sendete Acknowledge-Byte verpasst. Da- 
mit ein Wiederholungspaket auf diese 
Weise verworfen werden kann, muss der 
Empfänger es noch bestätigen. Damit weiß 
der Sender, dass er mit dem nächsten 
Block weitermachen kann. Beim Spectrum 
und Interface-1 ist genau dies fehlerhaft im- 
plementiert -— doch dazu später mehr. 
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Kommunikation zwischen Sender und Empfänger (Erklärung im Text) 


Netzwerk-"Broadcast"-Übertragungen 
sind im Wesentlichen gleich, abgesehen 
von der Art und Weise, wie Bestätigungen 
gehandhabt werden und wie lang die Scout- 
Phase ist. Beieinem QLohne TK2 wird kein 
Quittungs-Handshaking verwendet, was zu 
unzuverlässigen Übertragungen führt. Mit 
TK2 wird ein aktives ACK/negatives ACK 
zum Protokoll hinzugefügt. Es wird erst 
nach dem Ende des Datenpakets aktiv und 
verbessert die Zuverlässigkeit der Übertra- 
gung erheblich. Beachten Sie jedoch, dass 
dieser Aspekt nicht vollständig mit Nicht- 
TK2- oder Spectrum Broadcasts kompati- 
bel ist. 


Die Lücken beachten 


Zwischen jedem Versuch, ein Paket zu 
übertragen, sind Lücken zu sehen. Sie er- 
scheinen sowohl zwischen erfolgreichen 
als auch zwischen erfolglosen Übertragun- 
gen. Dabei ist die Länge der Lücke zwi- 
schen fehlgeschlagenen Versuchen nor- 
malerweise kürzer. Diese Übertragungs- 
lücken sind integraler Bestandteil des 
QLAN-Protokolls. Sie geben dem Empfän- 
ger Zeit, das letzte Paket zu verarbeiten, 
Auch geben sie dem Sender die Zeit, das 
nächste Paket vorzubereiten. Außerdem 
wird so die Leitung lange genug freigege- 
ben, dass ein anderes Stationspaar die 
Verbindung während der "Pause" in An- 
spruch nehmen kann. Die Verbindung kön- 
nen sich also mehrere Stationspaare in 
Form eines "Timesharings" teilen. Dieser 
Ansatz zur zeitlichen Aufteilung einer Ver- 
bindung ähnelt dem, was in der herkömm- 
lichen Netzterminologie als "Carrier Sense 
Multiple Access with Collision Detection" 
oder "CSMA/CD" bezeichnet wird. 

Um einen Hinweis auf die Auswirkungen 
dieser Lücken auf den effektiven Durchsatz 
zu erhalten, haben wir Messungen vorge- 
nommen, Zwischen zwei 7,5 MHz-QLs oh- 
ne andere laufende Aufträge und ohne 
beschädigte Pakete wird eine 32 kByte QL- 
Anzeigedatei in ca. 10,5 Sekunden über- 
tragen. Dabei entfällt etwa 45 % dieser Zeit 
auf die Lücken zwischen den eigentlichen 
Datenpaketen. Zwischen zwei Q68-Rech- 
nern hingegen wird dieselbe Datei in etwa 
6,3 Sekunden übertragen. Dabei entfallen 
nur 15 % der Gesamtzeit auf die Lücken. 
Das liegt zum Teil auf die schnellere Ver- 
arbeitung zwischen den Paketen. Dadurch 
ist jede Station schneller für das nächste 
Paket bereit. Dies führt zu Übertragungs- 
raten zwischen 3 kByte und 5 kByte pro 
Sekunde, je nach der Leistung der betei- 
ligten Rechner und der Mindestlänge der 
Lücke, die jeder von ihnen aushalten kann. 
Auf diese Weise wird ein höherer effektiver 
Durchsatz mit einer verbesserten Link-Aus- 
lastung und Effizienz bei gleicher Bit-Rate 
erreicht. 
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Hardware 


Fehlersuche im QNET 


Viele QL-Benutzer haben mit dem Anschluss ihrer QLs 
herum gespielt, um dann frustriert aufzugeben, ohne 
jemals die Vorteile der Vernetzung zu genießen. Hierfür 
gibt es mehrere mögliche Gründe. Die häufigsten sollen im 
Folgenden entweder hinsichtlich ihrer Ursache oder des 
beobachteten Verhaltens beschrieben werden. In jedem 
Fall werden mögliche Abhilfemaßnahmen genannt. 


Unzuverlässige QL-Hardware 

Bei der früheren Ausgabe-5-QL-Hauptplatine ist die 
ZX8302 ULA für das Netzwerk und die Mikrolaufwerke an 
den "umkämpften" Datenbus der Haupt-ULA des QL an- 
geschlossen. Das führt zu unregelmäßigen Zugriffszeiten, 
die QNET lahmlegen können. Manchmal funktionieren sie, 
an anderen Tagen nicht. Das Ersetzen durch ein Issue-6/7- 
Motherboard oder eine krude Modifikation des Iss-5- 
Boards, um die späteren Versionen nachzubilden, löst 
dieses Problem. Der Autor hat eine solche invasive Modi- 
fikation erfolgreich durchgeführt, würde sie aber nicht em- 
pfehlen! 


Verklemmte NET-Anschlüsse 

Es wird gelegentlich beobachtet, dass die Spannung am 

NET-Anschluss auf dem einen oder anderen logischen Pe- 
gel hängen bleibt. Das weist entweder auf einen defekten 
PNP-Transistor im NET-Ausgangsschaltkreis oder auf ein- 
en defekten oder schlechten ZX8302 ULA hin. Ein Ein- und 
Ausschalten des zuständigen QL kann den festsitzenden 
NET-Anschluss oft "befreien". 


Auswechseln des Transistors 

Der Austausch des TR2/ZTX-510 oder eines gleichwertig 
verbauten Transistors kann ebenfalls helfen. Dies gilt 
ebenso für eine obskure Modifikation, die einmal in einem 
QL-Magazin beschrieben wurde, nämlich das Einsetzen 
einer Diode in die Gnd-Leitung zum 5V-Linearspannungs- 
regler Der Autor hat diese Modifikation NICHT ausprobiert! 
Zum Zeitpunkt der Erstellung dieses Artikels sind Er- 
satzgeräte für den ZX8302 noch bei RWAPServices / Sell- 
MyRetro erhältlich. Der Autor empfiehlt, auf jeden Fall ein 
Ersatzgerät bereitzuhalten. 


Korrodierte NET-Buchsen 

Da sie in der Regel nicht benutzt werden, können die in- 
neren Kontakte der NET-Buchsen angelaufen oder sogar 
verrostet sein, was zu einer schlechten oder fehlenden 
Verbindung führt. Ein Versuch, die inneren Kontakte mit 
Isopropylalkohol und einem fusselfreien Tupfer o.ä. zu 
reinigen, kann helfen. In besonders schlimmen Fällen kann 
es nötig sein, die Buchsen abzulöten und durch eine ähn- 
liche Sorte zu ersetzen - wenn Sie sie noch finden 
können. Denken Sie daran, dass die beiden Steckdosen 
miteinander verbunden sind, so dass sich der Zustand der 
einen auf die andere auswirkt; behandeln Sie sie also ge- 
meinsam. 


Die Zeit, die in Lücken verbracht wird, 
mag verschwenderisch erscheinen. Es ist 
aber zu bedenken, dass diese Lücken für 
ein inhärentes Multitasking-Betriebssystem 
wie QDOS auch Zeitscheiben darstellen, 
die der CPU nun zur Verfügung stehen, um 
sich anderen Aufgaben und Arbeiten zu 
widmen. Diese wollen ausgeführt werden 
und halten ein höheres Maß an Reaktions- 
fähigkeit für den Benutzer aufrecht. Das 
Spectrum ROM hingegen, das von Natur 
aus Single Tasking ist, verwendet in der 
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Fehlerhafte Kabel 

Wenn Sie ein 2-adriges Kabel mit Klinkensteckern selbst 
hergestellt oder ein altes Kabel wiederverwendet haben, 
kann der Fehler in der Verbindung im gelöteten Stecker 
oder im Kabel selbst liegen. Prüfen Sie die 
Durchgängigkeit und stellen Sie sicher, dass die jeweiligen 
Pole des Klinkensteckers mit ihren Gegenstücken an 
beiden Enden verbunden sind (Spitze an Spitze, Hülse an 
Hülse). 


Falsche Verkabelung 

Bei mehr als ein paar miteinander verbundenen Maschinen 
kann man die Verkabelung erstaunlich leicht durcheinander 
bringen. Dadurch ist die eine oder andere Station nicht 
mehr angeschlossen, zu sich selbst zurückgeführt oder es 
ist eine unerwünschte "Schleife" zwischen den beiden 
äußersten Enden der Verbindung entstanden. Dadurch 
wird der NET-Leitungsabschluss deaktiviert. Es ist ratsam, 
eine laufende Übertragung an der Sendestation 
abzubrechen, bevor man die Kabel abzieht oder umsteckt. 
Der Autor hat allerdings noch keine bösen Überraschun- 
gen beim "hot-plugging" der Netzkabel erlebt! 


Fehlkonfigurierte Stations-IDs 

Gern wird der NET-Befehl vergessen, um jedem Gerät eine 
eindeutige Stations-ID zuzuweisen. Dies passiert beson- 
ders gern dann, wenn mehr als zwei Geräte an- 
geschlossen sind, Genauso gern wird bei der Eingabe des 
jeweiligen NETI_xINETO_x-Gerätenamens die Stations- 
ID der Maschine vergessen, an der Sie gerade tippen. 
Überprüfen Sie den NET-Befehl und geben Sie ihn erneut 
ein oder geben Sie den entsprechenden Gerätenamen 
erneut ein. 


Broadcast Fehler 

Die Netzwerk-Broadcast-Funktion der Station 0 (unter Ver- 
wendung von NETI_O/NETO_0) ist aufgrund des Fehlens 
einer aktiven "Bestätigung" im Broadcast-Protokoll nicht 
besonders zuverlässig. Testen Sie erneut eine direkte 
Peer-to-Peer-Dateiübertragung, um die Verbindung zu 
überprüfen, und wiederholen Sie dann die Übertragung. 
Das Aufrüsten eines alten QDOS-ROMs auf das wun- 
derbare Minerva-Betriebssystem kann auch die Net- 
zwerkübertragung zuverlässiger machen, da diese 
Funktion im NET-Treiber von Minerva neu kodiert wurde. 
Oder Sie fügen TK2 hinzu, das die Übertragungsfunktion 
vollständig durch eine wesentlich verbesserte Version er- 
setzt. 


Der QL scheint zu hängen 


Dies ist kein Fehler, sondern ein normaler Teil der Nutzung 
des Netzes. Interrupts innerhalb des "physischen" NET- 
Gerätetreibers werden während der Übertragung jedes 
Pakets abgeschaltet , um ein einheitliches Timing zu 
gewährleisten. Wenn Sie eine laufende Übertragung ab- 
brechen, versucht die sendende Station, das aktuelle 
Paket bis zu 2.000-mal erneut zu übertragen. Dabei wird 
die Tastatur kaum beachtet, auch wenn der Benutzer zwis- 


Regel kürzere Pausen zwischen seinen 
Übertragungsversuchen. Es tastet die Tas- 
tatur zwischen den einzelnen Paketen nur 
nach einem "Break" ab, ohne dass weite- 
re Benutzeraktivitäten möglich sind. Das 
passiert solange, bis das erwartete Paket 
erfolgreich empfangen und verarbeitet wur- 
de. 

Zusammenfassend lässt sich sagen, 
dass die QLAN- und ZXNet-Protokolle auf 
einem Mechanismus zur erneuten Übertra- 
gung von Paketen basieren (ähnlich wie 


chen den einzelnen Versuchen Strg+Leertaste drückt. Die 
Gegenstelle reagiert in der Regel besser auf die Tasten- 
kombination Strg+Leertaste. 


Beim 'Streaming' serieller Daten wird 
nichts empfangen 

Auch hier gilt, dass dies kein Fehler ist, wenn ein expliz- 
ites OPEN oder sogar ein COPY von einem anderen "seri- 
ellen" Gerät verwendet wird. Das Paket-/Blockdesign des 
NET-Treibers bedeutet, dass sich ein volles Paket von 255 
Bytes im Puffer des Absenders ansammeln muss. Erst 
dann wird der physische Treiber zur Übertragung über die 
Leitung aufgerufen. Da der aktuelle NET-Treiber keine 
'FLUSH'-Funktion besitzt, muss entweder die Ausgabe 
aufgefüllt werden, um den 255-Byte-Puffer zu füllen. Oder 
es muss ein CLOSE an der sendenden Station aus- 
gegeben werden. Wenn der NET-Treiber geschlossen wird, 
versucht er, das im Puffer befindliche Paket zu senden, 
unabhängig davon, wie voll es ist, und markiert dies als 
"letztes" Paket/Block. Dies wiederum führt dazu, dass die 
Empfangsstation eine EOF-Bedingung erkennt. 


Bad Parameter (BP)-Fehler 

Beim Empfang einer Datei mit LBYTES/EXEC usw. erwar- 
tet die Empfangsstation einen einfachen "seriellen 
Dateikopf". Dies sind die ersten 15 Bytes des allerersten 
Pakets, den sie erkennt und dessen erstes Byte "OxFF" ist. 
Die verbleibenden 14 Bytes des seriellen Headers enthal- 
ten die wichtige Dateilänge, das Byte "Datentyp" und - falls 
es sich um eine Datei vom Typ "Job" handelt- den Daten- 
bereich. Wenn das erste empfangene Byte nicht OxFF ist, 
schlägt der Befehl mit dem QDOS-Fehler 'Bad Parameter 
fehl. Ein BP-Fehler tritt auch auf, wenn das Dateityp-Byte 
im Header nicht mit den Erwartungen übereinstimmt. Ein- 
ige ältere Versionen von TK2 scheinen auch zu erwarten, 
dass LOAD mit einem seriellen Header arbeitet. Dieser 
wird aber nicht immer von dem entsprechenden SAVE 
gesendet. Aktualisieren Sie daher besser auf eine neuere 
Version von TK2 


Nach dem Laden von TK2 von der Disk 
funktioniert nichts mehr 

Aufgrund der sensiblen Software-Timing-Schleifen, die 
vom NET-Treiber verwendet werden, ist bei der Ausführung 
von TK2 aus dem RAM auf einem einfachen QL keine er- 
folgreiche Kommunikation möglich. Die RAM-Zugriffsbes- 
chränkung führt zu inkonsistenten Verzögerungen bei der 
Ausführung von Software oder beim Lesen und Schreiben 
ins RAM. TK2, das im inhärent unbeaufsichtigten ROM 
oder im RAM auf einer (Super)GoldCard läuft, vermeidet 
dieses Problem. Nachdem der Autor nun mehrere Jahre 
lang mit QL-Netzwerken und verschiedenen QLs und kom- 
patiblen Maschinen experimentiert hat, stößt er heute nur 
noch selten auf Probleme bei der Verwendung von QNET 
- außer denen, die er selbst verursacht! 


bei Ethernet). Dabei wird durchaus akzep- 
tiert, dass einzelne Pakete "verpasst" wer- 
den, wenn der Empfänger gerade nicht 
zuhört. Das Paket wird dann immer wieder 
neu gesendet, bis eine aktive Bestätigung 
eingeht und das nächste Paket zur Über- 
tragung in die Warteschlange gestellt wer- 
den kann. Der IOSS-Wiederholungs- 
mechanismus in QDOS ist daher ein 
wesentliches Standbein für das QLAN-Pro- 
tokoll. Der effektive Durchsatz hängt also 
in hohem Maße von der "Aufmerksamkeit" 


des Empfängers ab. Er ist weniger von der 
rohen Netzwerk-Bitrate abhängig und das 
ist ein Grund, warum der Q68 als Beispiel 
einen besseren Empfangsdurchsatz er- 
reicht als der Basis-QL. 


Alternativen zu QLAN 


Dieser Artikel hat bewusst die spannen- 
den IPNet/Ethernet-Projekte von Martin 
Head und die SERNET-Lösung ausge- 
klammert. Letztere wurde ursprünglich von 
Bernd Reinhardt entwickelt und basiert auf 
Phil Bormans MidiNet-Software. Es gibt 
noch weitere interessante und verwandte 
Projekte. So stellt das jüngste Retro-WiFi- 
Projekt eine drahtlose IP-Fähigkeit über die 
serielle Schnittstelle des QL her. Wir emp- 
fehlen Ihnen, bei Interesse selbst nachzu- 
forschen. Sie können in jedem Fall reichlich 
Informationen über diese anderen großar- 
tigen Projekte finden. 


Die TK2-Erweiterungen 
von QNET 


Während das NET-Basisgerät einige 
sehr nützliche Funktionen bietet, werden 
fast alle diese Funktionen mit TK2 verbes- 
sert oder anderweitig durch weiterentwi- 
ckelte Funktionen ergänzt. Um ehrlich zu 
sein, wird TK2 für alles gebraucht, was über 
die triviale Nutzung des QL hinausgeht. Es 
holt das Beste aus dem Gerät heraus, und 
das ist bei der Vernetzung sicherlich der 
Fall. TK2 ersetzt den gesamten einmal in- 
stallierten QDOS NET-Treiber. Die QLAN- 
Protokollspezifikation wird beibehalten, um 
eine grundlegende Kommunikation auch 
mit QLs ohne TK2 zu ermöglichen. Es ver- 
bessert die Zuverlässigkeit einiger Funkti- 
onen (z.B. Netzwerk-Broadcast) und fügt 
den wichtigen FSERVE-Server Job mit sei- 
nem entsprechenden 'Nx'-Gerätetreiber 
auf der Clientseite hinzu. Wie bereits er- 
wähnt, benötigt TK2 einen unbelegten 
RAM- oder ROM-Speicher, um das QL-ei- 
gene RAM-Zugriffsverhalten zu vermeiden. 
Andernfalls würde das empfindliche Timing 
des Bitlevel-Treibercodes durcheinander 
gebracht. 

Die grundlegende NET-Funktionalität 
bleibt wie zuvor beschrieben. Änderungen 
ergeben sich, sobald der FSERVE-Job auf 
einer oder mehreren der angeschlossenen 
Stationen aufgerufen wird. Dann ist es 
möglich, auf die Datei- und Geräteressour- 
cen auf der Server-Station zuzugreifen, als 
ob sie lokal installiert wären. Dies passiert 
durch die Verwendung des "Nx"-Client- 
Pseudogeräts. FSERVE ist flexibel genug, 
um der Client-Station fast alle Funktionen 
des entfernten Geräts zur Verfügung zu 
stellen. Auf dem Client muss TK2 installiert 
sein, FSERVE muss aber nicht laufen. Au- 


ßerdem kann vom Client aus auf jeden Ge- 
rätetreiber zugegriffen werden, der mit der 
bedienenden Station verbunden ist. Dies 
ist nicht beschränkt auf die offensichtlichen 
Dateisystemgeräte wie MDV, FLP oder 
WIN. So können SCR, CON, SER, PAR 
und andere auf der bedienenden Station 
installierte Geräte vom Client aus mit der 
gleichen allgemeinen Form Nx_<remote_- 
device_spec> angesprochen werden. Ei- 
nige wirklich clevere Netzwerk- Program- 
miertechniken eröffnen sich insbesondere 
mit dem MEM-Speichergerät (dank des 
DIYTK-Treiber von Simon N. Goodwins). 
Der größte Nutzen dieser Client-Server- 
Fähigkeit ergibt sich jedoch in der Praxis 
beim Laden oder Speichern von Dateien 
auf der Server-Station. Hier sind einige Bei- 
spiele; Nx steht dabei für N<server_stati- 
on-ID>. Zu beachten ist, dass nach dem 
Aufruf von FSERVE an der Server-Station 
nichts mehr eingegeben werden muss. 
Sicherung und Archivierung ganzer 
MDV-Kassetten über das Netzwerk 
in einen Ordner auf dem WIN-Ge- 
rät des Servers, mit einem einzigen 
Befehl auf der Client-Station: 
WCOPY 'mdvi_' TO 
'Nx_winl_backup_' 
Senden von Druckdateien an ein- 
en Qualitätsdrucker, der an den 
SER-Port des Servers an- 
geschlossen ist. Besser noch, ver- 
wenden Sie den Befehl SPOOL von 
TK2 anstelle von COPY: 
CoPY 'mdvi_print_txt' TO 
'Nx_serlihr' 
Senden von Nachrichten an die 
Bildschirmanzeige des Benutzers, 
der an der Bedienstation sitzt: 


OPEN 

#3, 'Nx_scr_100x20a206x118’: 
PRINT #3, ”Hello!”: PAUSE: 
CLOSE #3 


Laden von ausführbaren Program- 
men direkt aus dem Dateisystem 
des Servers: 
EX 
"Nx_winl_APPS_QED_ged’ ;"mdvl 
_text_file” 

Direkte Manipulation des Speichers 
(z.B. Video-Speicher) des Servers 
mit MEM: 
OPEN #3, '’Nx_mem’: PUT 
#3\131072: PRINT #3, 
FILL$ (CHR$ (170) &CHR$ (0) ‚3276 
7);: CLOSE #3 
Synchronisierung der lokalen 
Echtzeituhr (aus den Minerva-Dok- 
umenten) — wer braucht schon 
NTP? 
£$="Nx_raml_date_tmp”: 
d%=FOP_NENW (f$) 
IF d%>0 THEN CLOSE #d%: 
SDATE FUPDT(\f$): DELETE £$ 


FSERVES verborgener Schatz 


Es gibt eine verborgene oder zumindest 
wenig dokumentierte Funktion, die bei der 
Ausführung von FSERVE zur Verfügung 
steht. Sie ist von Vorteil beim "Bridging" 
zwischen einem QL und einem QL-Emula- 
tor auf einem PC oder anderen QL-Platt- 
form, die keine NET-Ports haben. Ein auf 
einer Zwischenstation laufendes FSERVE 
öffnet gerne im Namen des Clients ein 
Netzwerkdevice. Es ist auf eine andere 
Zielstation ausgerichtet. Haben Zwischen- 
server (Nx) und Zielstation (Sy) ebenfalls 
den SERNET-Treiber geladen und sind 
diese über ein geeignetes serielles Kabel 
miteinander verbunden, führt ein Befehl 
wie 

coPY ’mdvi_file’ TO 
"Nx_Sy_wini_file’ 

dazu, dass mdv1_file auf das WIN1_- 
Gerät des Emulators kopiert wird. Dies 
passiert, obwohl der emulierte QL nur in- 
direkt mit der Client-Station verbunden ist 
und selbst nur einen SERial-Port und keine 
QNET-Verbindung hat. Damit wird die 
derzeitige Einschränkung überwunden, 
dass sich QL-Emulatoren nicht direkt mit 
dem QL-Netzwerk verbinden können. 

In der Praxis erweist sich diese Über- 
brückung manchmal als schwerfällig. Dies 
liegt daran, dass jedes Paket, aus dem 
mdv1_file besteht, über die Zwischen- 
station "hüpfen" muss. FSERVE auf Nx 
verpackt es neu und gibt es an den SER- 
NET-Treiber weiter. Dieser liefert es an den 
endgültigen Speicherort auf dem WIN-Ger- 
ät des Emulators auf Station Sy aus. Eine 
weitere Erklärung für diesen Leistungsab- 
fall ergibt sich, wenn man bedenkt, dass 
der Client-Server-Treiber des TK2-Netzes 
das übliche "Befehl/Antwort"-Paradigma 
verwendet. Das führt zu einer zusätzlichen 
Latenz zwischen den einzelnen Daten- 
paketen führt. Für jeden gesendeten 
Datenblock sind zwei oder mehr "Befehls"- 
Pakete erforderlich. Obwohl dies bei der 
direkten Kommunikation von Station zu 
Station nur geringfügig auffällt, werden die 
Verzögerungen durch den zusätzlichen 
Sprung bei dieser Brückentopologie viel 
deutlicher. Der TK2-Client-Server verwen- 
det erweiterte Paketgrößen bis zu 1020 
Byte (obwohl Dateisystempakete typis- 
cherweise 524 Byte lang sind). Glücklich- 
erweise wird ein Teil der Bandbreiten- 
ineffizienz des SimpleNET-Geräts durch 
das Vorhandensein von weniger Paket- 
lücken für einen bestimmten Payload gem- 
ildert. 

Alles in allem ist dies eine wirklich nütz- 
liche Funktion von FSERVE in Kombina- 
tion mit seinem SERNET- Dateiserver- 
Äquivalent. Es ist wirklich ein Verdienst 
der Entwickler der einzelnen Treiber. Nur 
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aus akademischem Interesse oder zum 
Spaß können Sie diese Funktion auch in 
Aktion zwischen drei QLs beobachten, die 
nur das QLAN benutzen und auf denen TK2 
läuft. Die Client-Station Pakete lässt von 
einer Zwischenstation Nx bouncen, um das 
Ziel Ny zu erreichen, Versuchen Sie es mit 
einer 32KB QL-Anzeigedatei und dem Be- 


fehl: 
LBYTES 'Nx_Ny_winl_ql-dis- 
play_scr' ,131072 


Es wird funktionieren, aber nicht gerade 
atemberaubend sein. Abschließend ist zu 


bemerken, dass wider Erwarten jeder Ver- 
such, die Kette durch die Einführung einer 
weiteren Zwischenstation zu verlängern, 
völlig fehl zuschlagen scheint. 
coPY ’mdvi_file’ TO 
"Nx_Ny_Nz_winl_file’ 

Es ist noch nicht klar, warum diese Kon- 
figuration scheitern sollte. Einen prakt- 
ischen Nutzen hat sie besitzt sie allerdings 
nicht. 


Verbinden mit dem 
ZX Spectrum 


Ungeachtet der bekannten Probleme bei 
der Kommunikation zwischen dem QL und 


QLAN to USB Bridge (QLUB) Adapter 


Der QLAN to USB Bridge (QLUB) Ad- 
apter ist eine Open-Source-Lösung. Sie er- 
möglicht die die Verbindung und 
Kommunikation zwischen echter Sinclair 
QL-Hardware und einem QL-Emulator, der 
auf einem Host-PC läuft. Sie nutzt Sinclair's 
QLAN/QL-Net Protokoll und Verkabelung, 
mit Unterstützung für die TK2 QLAN Er- 
weiterungen, einschließlich FSERVE. 

Es gibt heute mehrere Möglichkeiten, 
Programme und Daten zwischen emuliert- 
er und QL-Hardware zu übertragen. Dies 
schließt SERNET und herausnehmbare 
SD-Kartenmedien ein. Diese erfordern je- 


PCB der Prototypen des QKUB Adapters 


doch entweder zusätzliche Hardware oder 
Software auf der QL-Seite. Sie schränken 
daher ihre Zugänglichkeit für "nicht erweit- 
erte QL"-Benutzer ein. QL-Net hingegen ist 
in alle QLs eingebaut und ist daher selbst 
mit einer minimalen QL-Konfiguration kom- 
patibel. 

Der QLUB-Adapter besteht sowohl aus 
Hardware- als auch aus Softwarekompon- 
enten. Die Hardware basiert auf einer Mik- 
rocontroller-Entwicklungsplatine (Teensy 
++2.0) mit kundenspezifischer Firmware 
und einigen zusätzlichen Komponenten. 
Außerdem gibt es eine Software, die in 
einem QL-Emulator auf dem Host-PC läuft. 


Sie schafft eine Schnittstelle zwischen 
QDOS/SMSQE-Client-Anwendungen oder 
Gerätetreibern und dem Mikrocontroller, 
der über einen freien USB-Anschluss mit 
dem Host-PC verbunden ist. Der Adapter 
erfordert einige zusätzliche Komponenten, 
die leicht erhältlich sind. Sie sind für die 
meisten Enthusiasten einfach genug, um 
auf einer Lochrasterplatine mit minimalem 
Lötaufwand zusammengebaut zu werden. 

Es wurde auch ein SBASIC-Programm 
entwickelt, um das Senden und Empfan- 
gen von Dateien zwischen dem QL Emu- 
lator und einem anderen QL (oder einem 


Bild: https://qlforum.co.uk/ 


kompatiblen Gerät) zu testen. Es funk- 
tioniert bereits bei der Übertragung von 
Dateien zwischen diesen Plattformen. 
Diese "Proof- 
of-Concept"- 
Software wurde 
der QL-Com- 
munity in diesem 
Stadium der Vor- 
abveröffent- 
lichung zur 
Verfügung ges- 
tellt (Dezember 
2020). Zusam- 
men mit der 


dem Spectrum über QNET/ZXNet gibt es 
einige nützliche Dinge, die möglich werden, 
wenn diese beiden Geräte miteinander ver- 
bunden sind. Sie sind es wert, hier genau- 
er betrachtet zu werden. Während der 
Nachforschungen über den Anschluss des 
ZX Spectrum entdeckte der Autor, dass 
Sinclair möglicherweise ZXNet — oder den 
"Sinclair Network Standard" — als Kernbe- 
standteil des ursprünglichen ZX82/Spec- 
trum-Designs ins Auge gefasst hatte. 
Zunächst wurde seine Übernahme als "of- 
fenen Standard" gefördert. Später jedoch 
wurde er von der Spectrum-Hardware und 


neuesten Mikrocontroller-Firmware und 
einer Anleitung sollen so Anwendertests er- 
möglicht sein. Die die Arbeit an der Soft- 
ware wird währenddessen fortgesetzt. Sie 
wird die letztendlich vollständig in in 
QDOS/SMSGQE im Emulator integriert. 

Der QL-Emulator QPC2 wurde während 
des gesamten Entwicklungszyklus verwen- 
det. Die endgültige Lösung sollte jedoch 
mit jedem QL-Emulator kompatibel sein. Er 
muss dazu nur die COM/seriellen Schnitt- 
stellen des Host-PCs zugänglich machen 
und es braucht einen geeigneten USB Vir- 
tual COM Port Treiber für den Atmel Mik- 
rocontroller. 

Da der ZX Spectrum mit dem Interface- 
1 auch kompatible Netzwerk-Hardware und 
-Software bietet, funktioniert der QLUB 
ebenso gut mit einem Spectrum. Sogar ein 
Spectrum Next mit Int-1 ließe sich verbind- 
en. Das gleiche gilt für jede QL-ähnliche 
Lösung, die die QLAN NET-Port-Hardware 
enthält, wie z.B. der Q68, QXL und Aurora 
andere. 

Seit März 2021 funktioniert die Mikrocon- 
troller-Firmware und der größte Teil der 
Software-API-Schnittstelle und der Entwurf 
der Datenstruktur wurde abgeschlossen. 
Auch die Realisierung der "Message- 
Queue"-Server, die den Adapter mit QDOS 
verbindet, war weit fortgeschritten. Nach 
der Beseitigung einer Reihe von Fehlern 
wurde eine vollständige Fassung für den 
Herbst 2021 angekündigt. 

Die aktuelle Fassung der Bauanleitung 
ist auf der Heft-CD zu finden. 


Gedrucktes Gehäuse eines Prototypen 


Bild: https://qlforum.co.uk/ 


ihrem 16K-ROM-Basisgerät gestrichen. 
Schließlich tauchte er in Form des Inter- 
face-1 Add-ons wieder auf. 

Einer der vielen Spectrum-ROM-Neuent- 
wickler, Geoff Wearmouth, ging sogar so 
weit, die ZXNet-Routinen in sein Ersatz- 
16K-ROM (The Sea Change ROM) zu im- 
plementieren. Es verwendet die Interface- 
1-Hardware, aber nicht deren Firmware. In 
jedem Fall haben der Basis-QL und Spec- 
trum/Interface-1 ein völlig kompatibles Pro- 
tokoll für ihre jeweiligen Netzimplementie- 
rungen. 

Wie kommt es dann, dass die meisten 
Benutzer nicht in der Lage waren, die Spec- 
trum/QL-Verbindung für sich nutzbar zu 
machen? Die Netzwerkkommunikation von 
Spectrum zu Spectrum erscheint ja relativ 
brauchbar. Während der Untersuchung die- 
ser interessanten Tangente zum QL-Netz- 
werk durch den Autor wurden mehrere 
Fehler im Interface-1 Netzwerkcode iden- 
tifiziert. Der wichtigste von diesen betrifft 
das inkonsistente Timing beim Senden be- 
stimmter Bitmuster vom Spectrum. Die Ur- 
sache wurde beim Schreiben des nächsten 
Übertragungsbits in das Interface-1 ULA- 
Register als "IO Contention" festgestellt. 
Diese Feststellung deckt sich mit der allge- 
meinen Beobachtung, dass einerseits der 
Übergang von QL zu Spectrum recht gut 
funktioniert. Andererseits kommt nur selten 
etwas vom Spectrum zurück, was seinen 
Nutzen stark einschränkt. Dieses Verhal- 
ten wurde inzwischen diagnostiziert. Es 
wurden Ersatz-Z80-Routinen entwickelt 
und getestet. Sie beseitigen neben ande- 
ren subtilen Fehlern auch das ULA-Con- 
tention-Problem. 

Der Austausch des Interface-1-ROM ist 
nicht trivial,‚um es milde auszudrücken. 
Dies liegt zum Teil an den außergewöhn- 
lich engen Abständen innerhalb des ele- 
ganten Interface-1 Gehäuses. Nichtsdesto- 
trotz hat der Autor eine zuverlässige 
Kommunikation zwischen diesen Maschi- 
nen mit den modifizierten Interface-1-ROM- 
Routinen erreicht. Er würde den Code ger- 
ne mit interessierten Benutzern teilen, die 
bereit sind, ihre wertvolle Interface-1-Hard- 
ware zu modifizieren. 

Alternativ dazu kann der QL mit Hilfe ei- 
nes leicht überarbeiteten QNET/TK2-Trei- 
bers auf dem QL und der Anpassung einiger 
Timing-Konstanten besser an die wackeli- 
gen Bit-Timings des Spectrum angepasst 
werden. Dies vermeidet eine Modifikation 
des Interface-1. Das Ergebnis ist nicht 
100%jig perfekt, aber ein guter Schritt. 

Glücklicherweise können der mit SGC 
ausgestattete QL sowie der QXL die Zeit- 
anomalie des Spectrum bereits ohne wei- 
tere Anpassungen bewältigen, wenn auch 
nicht immer zu 100% zuverlässig. Dies gilt 
möglicherweise auch für den GC. Der 068, 


der mit dem ND-Q68-Treiber betrieben 
wird, scheint dagegen mit den Wacklern 
des Spectrum gut zurechtzukommen. 
Wie auch immer es erreicht wird, sobald 
eine zuverlässige Verbindung hergestellt 
werden kann, eröffnen sich viele Möglich- 
keiten: 
Sicherung der ZX-Microdrive-Kas- 
setten auf einem zuverlässigen QL- 
Speicher 
Bequeme Entwicklung von Spec- 
trum-Software in einem Emulator 
auf dem QL (z.B. Speculator oder 
dem brillanten ZM/x) und Rücküber- 
tragung auf einen "echten" Spec- 
trum 
Übertragen von Bildschirmkopien 
Ihrer Lieblings-Spectrum-Spiele 
rendern Sie auf dem QL mit zusätz- 
licher QL-Software 
Multiplayer-/Multiplattform-Netz- 
werkspiele 
QLAN kann also auch hier einen echten 
Mehrwert bieten. 


Übersetzung und redaktionelle Bearbeitung: 
Georg Basse (mit der freien Version von 
www.deepl.com) 


Das Original dieses Arti- 

kels mit Programmbeispie- 

I len und weiteren Informa- 

tionen findet sich auf der 
Heft-CD 
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ı Sir Clive Sinclair, 
Erfinder und Gründer 
von Sinclair Re- 
' search, hat sehr früh 
als Erfinder von sich 
Reden gemacht, 
Schon 1958 hatte er 
als Schüler ein Minia- 
turradio entworfen. Er 
schrieb in Fachjourn- 
alen über HiFi Technik und gründete im Alter von 
21 Jahren seine erste Firma, Sinclair Radionics. 
Mit Taschenradios, Stereoverstärkern und Laut- 
sprechern hatte er durchaus Erfolg am Markt. Etwa 
2 Mio. Pfund spülte dann der Executive in die 
Kassen, ein schicker, auf die Grundrechenarten re- 
duzierter Taschenrechner. Nachfolgeprodukte wie 
die erste Digitaluhr und ein Taschenfernseher 
hingegen floppten. 
Zusammen mit Tim Curry hatte Sir Clive mit seinem 
neuen Unternehmen Sinclair Research mehr Er- 
folg. Die kleinen, preiswerten Modelle Sinclair 


Links 


SuperBASIC/SBASIC Reference Manual 
Online: 

https://superbasic- 
manual.readthedocs.io/en/latest/ 
index.html 

QL Benutzerhandbuch: 
http://www.dilwyn.me.uk/docs/ebooks/ 
olglug/index.htm) 

QL68 Nachrüstung: 
https://www.glforum.co.uk/viewtopic.php?f 
=3&1=2881 

Paketaufbau ohne TK2: 
https://superbasicmanual.readthedocs.io/e 
n/latest/Appendices/Appendix 17.html#a17 
-1-4-gnet-without-toolkit-ii 

Reinigen der NET Buchsen: 

https ://qlforum.co.uk/viewtopic.php? 
f=128&1=3279 

SeaChange ROM für Spectrum: 
http://zxspectrum.it.omegahg.com/rom/ 
seachange/seachange.pdf 


ZX80, ZX81 und ZX Spectrum brachten zu Beginn 
der 1980er Jahre den Computer in viele Haushalte. 
Trotz offensichtlicher Qualitätsmängel und Design- 
fehler machte Sinclair 14 Mio. Pfund Gewinn pro 
Jahr und Sir Clive zu einem reichen Mann. Sein 
Erfolg brachte ihm 1983 den Ritterschlag ein. Sein 
letzter Rechner, der Sinclair QL, sollte das Profi- 
Segment erobern. Doch eine übereilte Marktein- 
führung und halb fertige Software ließ das Gerät 
zum Misserfolg werden. Endgültig in die roten Zah- 
len wurde Sinclair Research durch den C5 kata- 
pultiert, ein Elektro-Dreirad für eine Person. 
Sicherheits- und Qualitätsmängel ließen das Pro- 
jekt nach 17.000 produzierten Fahrzeugen sterben. 
Sir Clive verkaufte schließlich 1986 sein Unterneh- 
men an den Konkurrenten Amstrad. 

In der Folgezeit konzentrierte sich Sir Clive auf 
seine Arbeit in einer Stiftung für Hochbegabte und 
machte Karriere als Pokerspieler. Er erlag am 
16.September 2021 in London seiner langen 
Krankheit. 
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Eine PET Replika mit Extras 


Der Micro-PET 


Der Micro-PET ist eine “Neuauflage” des Commodore- 
PET von 1977 und seinen Nachfolgemodellen. Sie 
umfassen die Modelle bis zum 8296 aus den Jahren 1984 
bis 1986. Der Commodore PET zählt zusammen mit dem 
Apple-Il und dem TRS-80 zu der “1977 Trinity”. 


Der Commodore PET nutzt — wie auch 
einige andere Rechner dieser Zeit — den 
MOS 6502 als Prozessor und lässt ihn mit 
1 MHz laufen. Die monochrome Bild- 
schirmausgabe -— meist Phosphorgrün auf 
Schwarz — wird am Anfang komplett mit Lo- 
gik-Chips aufgebaut. Erst später kommt 
mit dem CRTC6545 ein programmierbarer 
Video-Chip hinzu. Der Bildschirm ist fest 
eingebaut. 

Der Speicher läuft nur mit 1 MHz, des- 
halb muss die CPU auf den Bildschirm (Ver- 
tical Retrace) warten, um auf den Bild- 
schirmspeicher zuzugreifen. Dies wurde 
später behoben. Apropos Speicher: Die er- 
sten Modelle hatten 4 KByte RAM, wur- 
den aber schnell auf 8 KByte 
aufgerüstet. Der “normale” PET 
hat dann 32 KByte und nur 
die späten 8296-Modelle 
haben 128 kByte RAM. 
Als Peripherie ist in den 
ersten Modellen ein Tape- 
Deck neben dem Key- 
board eingebaut. Der Be- 
griff “Datasette” war 
damals noch nicht erfun- 
den. Spätere Modelle 
haben das nicht mehr, dafür aber ein 
größeres Keyboard. Eine Besonderheit ist 
die Nutzung des IEEE488 Bus zum An- 
schluss von Peripheriegeräten. Dieser 
auch als “HP-IB” oder “GP-IB” bekannte 
und von Hewlett-Packard entwickelte Bus 
erlaubt es, mehrere Peripheriegeräte an- 
zubinden und über eigene Adressen zu ver- 
wenden. Dieser Bus wird noch heute in 
der Forschung und Entwicklung für die An- 
bindung von intelligenten Mess- und 
Steuergeräten verwendet. 

Commodore baute dafür eine Serie von 
Floppy-Disk-Laufwerken. Diese konnten 
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mit dem ersten Set 
von ROMs aber noch gar nicht ange- 
sprochen werden. Die Laufwerke waren 
noch nicht fertig, der Code ungetestet und 
außerdem fehlerhaft. All das wurde in 
späteren Versionen bereinigt. Mit aus- 
geliefert wurde das Microsoft-BASIC. Com- 
modore hatte das BASIC von Microsoft 
gekauft und nicht etwa lizenziert, wie es 
später bei Microsoft üblich wurde. Com- 
modore hat tatsächlich dafür eine Ein- 
malzahlung geleistet — Bill Gates hat hier 
wohl in Commodore CEO Jack Tramiel ei- 
nen würdigen Gegner gefunden. Beim 


Einschalten des Commodore PET er- 
scheint ebenso wie beim C64 die Meldung 
mit dem typischen READY Prompt auf dem 
Bildschirm. Insgesamt ist der Commodore 
PET aus vielen Standard-Logikbausteinen 
aufgebaut, ergänzt durch ein paar der typis- 
chen 65er-I/O Chips. Insbesondere werden 
neben dem 6502 Prozessor die 6522 VIA, 
zwei 6521 PIA und der 6545 CRTC verwen- 
det. Dies wird im folgenden noch wichtig 
sein. 

Wie aus dieser Be- 
schreibung zu sehen ist, 
war der Commodore 

PET in gewissem Sinne 

ein Vorläufer des 

VC2O und des CB64. 

Mit diesen teilt sich 

der PET sich einige 

Dinge wie das BA- 

SIC, den Kernel, 

das Tape Interface 

und den IEC-Bus 

als eine hard- 

wareseitig ver- 
einfachte 
Variante 

IEEE488. 

Durch seinen 

Erfolg selbst, 

aber auch 

durch seine 

Äh “Vaterschaft” am 

C64 hat sich der 

PET seinen Platz in 

den Geschichtsbü- 

chern verdient. 


des 


Ziele des Micro-PET 


Der Micro-PET sollte eine Open Source 
Replika des Commodore PET werden, der 
zum einen mit aktuell noch verfügbaren ICs 
gebaut werden kann. Zum anderen sollte 
er zusätzlich eben auch moderne Features 
besitzen: mehr Speicher, höhere Taktfre- 
quenz und modernere Peripheriegeräte. 
Ganz besonders wichtig war das Ziel, den 
Micro-PET auch mit einem VGA Monitor 
nutzen zu können. Damit wird es einfach, 
ihn an moderne Monitore anzuschließen. 


Bildnachweis: en.wikipedia.org, Tomislav Medak from Flickr / Editing: Bill Bertram (Pixel8) Creative Commons License 


Zwar braucht man inzwischen meist einen 
HDMI-Adapter, doch erlaubt das VGA-ba- 
sierte Timing damit die Nutzung von HD- 
MI-Monitoren. In dem Zusammenhang soll- 
te es auch möglich sein, verschiedene Mo- 
delle des PET abzubilden — von den 40-Zei- 
chenmaschinen mit 32k bis zu den 80-Zei- 
chenmaschinen mit 128k. Dies sollte auch 
mit Software umschaltbar sein, um Dip- 
Switches oder ähnliches zu vermeiden. Des 
weiteren sollten die Erfahrungen, die der 
Autor mit SPl-basierten Ethernet-, USB- 
und SD-Card Schnittstellen gesammelt hat- 
te genutzt werden, um diese Schnittstellen 
dem PET beizubringen. Und zu guter Letzt 
sollte das ganze mit einer „vernünftigen” 
Tastatur in einem ansprechenden Gehäu- 
se unterzubringen sein. 


Systemübersicht 


So wie der PET im Grunde genommen 
ein relativ einfaches System ist, so wurde 
auch der Micro-PET ein recht einfaches 
System. Das Diagramm zur Systemarchi- 
tektur zeigt das deutlich. Auf der oberen 
rechten Seite ist ein einfaches 6502-Sys- 
tem zu sehen, mit der 65816 CPU, RAM 
und den drei aus dem PET stammenden 
V/O-Chips VIA und PIA1/2. Auffällig ist das 
fehlende ROM - dazu gleich mehr. Links 
davon ist der große CPLD - ein „Complex 
Programmable Logic Device“. Dieser über- 
nimmt die Aufgabe des CRTC Video-Chips 
aus dem PET und hat dazu - eigentlich 
ganz analog zum Original PET - ein eige- 
nes Video RAM. Nur sind die RAM-Bau- 
steine nicht in 1 KByte zu bemessen, 
sondern eher 512kB. Dieser CPLD über- 
nimmt damit praktisch die gesamte Logik 
der Adressselektion und Videogenerierung. 
Rechts unten im Diagramm ist noch der 
SPI-Bus (Serial Peripheral Interface Bus) 
zu sehen. An diesem hängen verschiede- 
ne Geräte wie ein Flash ROM, ein USB-In- 
terface Chip, Ethernet, batteriegepuffertes 
RAM sowie eine SD-Card Schnittstelle. 


CPU und Speed 


Die verwendete CPU ist eine 65816 vom 
Western Design Center. Diese hat einen 
Nachteil und zwei Vorteile:Der Nachteil ist 
die fehlende Unterstützung der sogenann- 
ten „illegal Opcodes” des 6502. Diese wer- 
den insbesondere häufig auf dem C64 zur 
Code-Optimierung in Spielen und Demos 
verwendet. Auf dem PET sind solche Pro- 
gramme aber nicht bekannt. Der erste Vor- 
teil ist, dass die CPU von Haus aus 16 bit 
verarbeiten kann und auch einen Adress- 
bereich von 16 MByte verwaltet. Das ist 
insbesondere wichtig bei der Adressierung 
des Micro-PET Speichers von 1 MByte 
RAM. Der zweite Vorteil liegt in der Ge- 
schwindigkeit. Die CPU ist deutlich schnel- 
ler als die originale 6502 CPU. Eine 65816 


Systemaufbau des Micro-PET 


CPU ist für einen Takt von bis zu 14 MHz 
spezifiziert. Verschiedenen Berichten zu- 
folge kann sie aber deutlich schneller be- 
trieben werden. Die C64 “SuperCPU” hat 
diesen Prozessor ebenfalls verwendet — 
sogar mit eigentlich nicht spezifizierten 
20MHz. 

Im Micro-PET wird die CPU grundsätz- 
lich mit 12.5MHz betrieben. Dies dient da- 
zu, die Videoausgabe mit der CPU syn- 
chron zu halten und genug Bandbreite für 
VGA-basiertes Videotiming zu bekommen 
(siehe unten). Über ein Konfigurationsre- 
gister kann die Geschwindigkeit aber auf 
PET-kompatible 1MHz, 2MHz, oder 4MHz 
gedrosselt werden. 


Boot, ROM und Memory Map 


Wie oben bereits erwähnt, fehlt auf der 
65816-Seite der Maschine ein ROM. Da- 
her lädt das CPLD vor dem Starten der 
CPU eine Speicherseite (256 Byte) aus 


Video +----+ 35100000 
RAM | I VRAM 
| I bank 15 
+----+ $0f00009 
| | 
| | 
+----+ 5090000 
| I VRAM 
| I bank 8 (video) 
+----+ 5080000 
Fast | I FRAM 
RAM | I bank 7 


+----+ 5070000 


+----+ 5020000 
FRAM 


+----+ 3010000 


+----+ 5000000 


Speichernutzung des Micro-PET Memory Map) 


dem SPI Flash ROM und speichert es im 
RAM in der obersten CPU Speicherseite 
($FFxx). Damit bootet die 65816 CPU und 
kann allen weiteren Code vom Flash ROM 


selbst nachladen. Das vermeidet die Nut- 
zung von parallel angesprochenen 
EPROMSs , die in der Regel langsamer sind 
als das RAM und auch auf der Platine deut- 
lich mehr Platz beanspruchen. Alle Berei- 
che, die im normalen PET als ROM 
ausgeführt sind, sind damit hier als RAM 
ansprechbar . Über ein Konfigurationsre- 
gister können diese Bereiche schreibge- 
schützt werden, um ein ROM zu simulieren. 
So ist es auch einfach, beispielsweise ge- 
änderte „ROMs” einzuspielen und zu tes- 
ten oder zu nutzen. 

Da der Micro-PET 1MByte RAM hat, ist 
der Speicher so aufgeteilt wie im Diagramm 
gezeigt. Die ersten 512kByte sind das so- 
genannte Fast RAM - hier gibt es keine 
Konflikte im Speicherzugriff während der 
Videoausgabe. Die zweiten 512k dienen 
als Video RAM - hier kann der CPLD die 
CPU anhalten, wenn der Zugriff auf den 
Speicher durch die Videoausgabe erfolgt. 
Damit der PET emuliert werden kann, sind 
in Bank O0 die Speicherbereiche $8xxx und 
$E8xx gesondert gehandhabt: 


bank 1 (8296 mapped memory) 


FRAM (PET ROM / I/O / 4k Video mapped from VRAM) 
FRAM (lower 32K) 
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$8xxx — Dies ist ein Fenster in den 
Videospeicher. Statt des in Bank O0 
normal genutzten Fast RAM wird 
hier das Video RAM verwendet, um 
den Inhalt wie beim PET auf den 
Bildschirm auszugeben. 
$E8xx — Dies ist der I/O Bereich des 
PET. Hier werden die auf der Plati- 
ne befindlichen VIA und PIA ange- 
sprochen, um die Tastatur oder den 
IEEE488 Bus zu bedienen. 
Zusätzlich besteht die Möglichkeit, die 
oberen 32 KByte der Bank 0 in zwei Blö- 
cken zu 16k aus der Bank 1 zu mappen. 
Dies entspricht der Speicherverwaltung des 
8296, so dass auch dieses Modell korrekt 
nachgebildet wird. Anders als beim echten 
PET können auch die unteren 32 KByte der 
Bank 0 in eines von 16 Pages mit je 32 
KByte des Fast RAM gemappt werden. Da- 
mit können beispielsweise unabhängige 
Programme im “time sharing” der CPU par- 
allel laufen, ohne dass aufwändig Zeropa- 
ge oder Stack gesichert werden müssten. 


Video 


Die Video-Ausgabe findet grundsätzlich 
im Modus 640x480 bei 60 Hz statt. Dies er- 
laubt eine Darstellung von bis zu 80 Zei- 
chen pro Zeile bei 50 Zeilen (also 8 oder 9 
Pixelzeilen pro Zeichen). Ein Konfigurati- 
onsregister kann die Bildschirmauflösung 
aber auch an den Original-PET mit nur 40 
oder 80 Zeichen pro Zeile bei 25 Zeilen an- 
passen. Ebenso kann die Videoausgabe in 
einen Hires Modus umgeschaltet werden. 
Die Ausgabe erfolgt dabei immer mono- 
chrom. Aufgrund von Platzproblemen im 
CPLD ist der in späteren PETs verbaute 
CRTC Video-Chip nur sehr begrenzt nach- 
zubilden. So ist nur die Startadresse des 


Die fertig aufgebaute Platine 


Speichers, so- 
wie die Höhe ei- 
nes einzelnen 
Zeichens (8 oder 
9 Rasterlinien) 
einstellbar. Der 
CPLD ist in einer 
zweiten Variante 
aber auch als A, 
“4032” zu pro- BYE 
grammieren —- es 
sind dann nur 40 
Zeichen und kei- 
ne der weiteren 
Funktionen für 
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handen. Aller- Der Micro-PET im C64 Gehäuse 
dings werden 


wesentlich mehr CRTC- Register simuliert. 


Kompatibilität 

Zugegebenermaßen wurde noch nicht 
alle PET Software getestet. Allerdings läuft 
das “8296 burn-in” Programm erfolgreich 
durch und bestätigt damit die Grundfunkti- 
onen. Bisher ließ sich auch kein Programm 
finden, das auf dem Micro-PET nicht läuft 
—- solange es nur die einfache CRTC-Emu- 
lation benötigt. Die “No PETs Allowed” De- 
mo läuft zwar mit der oben erwähnten 4032 
Simulation, aber noch nicht “rund” — wobei 
das natürlich schon die höchsten Ansprü- 
che stellt. 


Zum Bauen 


Wer einen Micro-PET haben will, muss 
ihn im Moment noch selbst bauen. Alle In- 
formationen, die dazu nötig sind, liegen im 
Github Repository des Micro-PET. 


” 
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Dazu gehören: 
Schaltplan des Boards und Eagle 
Layout, mit dem man sich die Plati- 
nen herstellen lassen kann, sowie 
eine Stückliste (inkl. Mouser Be- 
stellnummern) 

VHDL-Code für den CPLD, mit ent- 
sprechenden Build- und Program- 
mier-Anweisungen für das Xilinx 
Web-ISE IDE 
Scripts, um das Image für das 
Flash-ROM zu bauen (basierend 
auf Steve Gray’s Editor ROM Pro- 
jekt) 

Designs für 3D-druckbare Teile, mit 
denen die Platine mit einem PET 
Keyboard in ein C64c Gehäuse ein- 
gebaut werden kann 


Fazit 


Mit dem Micro-PET steht eine neue Fas- 
sung des Commodore PET mit hoher Kom- 
patibilität, aktuell noch lieferbaren Bau- 
steinen und modernen Schnittstellen zur 
Verfügung. Durch den Einbau in ein C64c- 
Gehäuse und VGA Video-Anschluss lässt 
sich das “PET Feeling” auch heute noch 
einfach auf echter Hardware erleben! 
Durch das offene Design können sich alle 
daran beteiligen und das System weiter- 
entwickeln. So ließe sich auch eine Plati- 
ne entwerfen, die statt dem bisherigen 
Euro-PCB Format auf den Original-Form- 
faktor des C64 oder gar des PET hat. So 
wäre verwaisten Gehäusen ein neues Le- 
ben einzuhauchen. 


Links 


http://www.6502.org/users/andre/ 
upet/index.html 
https://github.com/fachat/MicroPET 
http:/www.6502.org/users/andre/csa/ 
index.html 
https://en.wikipedia.org/wiki/ 
Commodore_PET 


Interview mit Autor 
und Micro-PET Ent- 
wickler Andre Fachat 


LOAD: Wie bist zu dazu ge- 
kommen, Dich mit Commo- 
dore Computern zu befas- 
sen? 


Andre: Ich habe das Pro- 
grammieren in der Schule auf 
einem Commodore PET 3032 
gelernt, bevor ich dann meinen 
eigenen C64 bekam. Da habe 
ich dann schnell gemerkt, dass 
meine Lieblingsprogramme 
und Spiele nicht so einfach auf 
dem C64 liefen. Da ich zur 
Schulzeit bereits mit einem 
Freund an 6502-basierten Sys- 
tem gearbeitet habe, nahm ich 
mir zu Beginn des Studiums 
dann vor, eine PET-Replika zu 
bauen. Das war 1989. 


LOAD: War das bereits der 
Anfang des MicroPET? 


Andre: Nein, eigentlich nicht. 
Die erste PET-Replika ist der 
CaSpAer (aka CS/ A65), ein 
Multiboard-Computer auf Eu- 
rokartenbasis. In den letzten 
Jahren habe ich sogar eine 
Karte mit Ethernet, USB, und 
SD-Card Unterstützung ge- 
baut. 


LOAD: Das klingt doch 
nach einem großen Erfolg. 
Was hat Dich motiviert, ein 
neues Projekt anzugehen? 


Andre: Bei der Weiterent- 
wicklung des CaSpAer habe 
ich festgestellt, dass die Tech- 
nologie seit 1989 um einiges 
weiter gezogen ist. Diese Kar- 
te war schon nur 10x10cm 
groß, aber die Umsetzung auf 
3.3V und SPI (Serial Peripheral 
Interface)-basierte Anbindung 
hat allein schon die halbe Kar- 
te ausgemacht. Die eigentliche 
Peripherie war noch viel klei- 
ner. Daher war es schon lange 
auf meiner TODO-Liste, eine 
moderne PET-Replika zu bau- 
en, die dann auch VGA-Bild- 
schirme nutzen kann. 


LOAD: Jetzt existieren ja 
bereits andere Projekte, die 
einen PET nachempfinden. 
Was unterscheidet den Mi- 
cro- PET von diesen Geräten, 
zum Beispiel vom Mini-PET? 


Andre: Nachdem der Mini- 
PET herauskam und ich ehrli- 


cherweise nicht von dessen 
Features überzeugt war, habe 
ich mich entschlossen, meinen 
Plan endlich in die Tat umzu- 
setzen und den Micro-PET zu 
entwerfen. Der Micro-PET hat 
ein quell-offenes Design und 
kann von allen Interessierten 
weiterentwickelt werden. 


LOAD: Hast Du den Micro- 
PET allein entworfen oder 
hattest Du Mitstreiter? 


Andre: Der Micro-PET ist ei- 
ne komplette Eigenentwick- 
lung und komplett auf meinem 
Mist gewachsen. Mitstreiter 
hatte ich keine. Nicht etwa, weil 
ich nicht das wollte, ich habe 
es nicht als nötig angesehen. 
Ich hatte eine Vision davon, 
was ich bauen wollte und im 
Prinzip alle Ideen schon mal 
anderweitig ausprobiert, die 
musste ich nur kombinieren. 
Nur den VGA Ausgang und das 
SPI-Boot habe ich in Revision 
1 des Micro-PET getestet, mit 
parallelem ROM und Compo- 
site Video als Fallback für den 
Fall, dass es nicht geklappt 
hätte. Außerdem ist bei einem 
größeren Team die Gefahr vor- 
handen, dass man sich zu sehr 
in Diskussionen verzettelt. An- 
dere Projekte haben darunter 
schon gelitten. 


LOAD: Manche Projekte 
scheuen sich ja, ihre Ent- 
wicklungen quelloffen anzu- 
bieten. Sie befürchten, dass 
sich dann Dritte darüber her- 
machen und mit Bausätzen 
oder Fertiggeräten auf den 
Markt kommen. Wie stehst 
Du dazu? 


Andre: Ich würde mich sogar 
freuen, wenn jemand das auf- 
greifen würde und den Micro- 
PET fertig oder als (SMD-ferti- 
ges) Kit vertreiben würde, da 
es das Commodore PET “Fee- 
ling” weiter verbreiten würde. 


4 Ein Clone des 
Git Repository ist 
auf der Heft-CD 


u 


Zum 


kK1355S51iS5cCcher 
Computer 8.3. 


Einer für Alle! 


Ein Computer-Verein für alle klassischen 
Computer-Systeme? Na klar! 


Egal ob Großrechner der 70er, Home-Computer 
der 80er oder PCs der 90er. Wir haben sie alle. 
Komm, mach mit und entdecke die faszinierende 
Welt der klassischen Computer bei uns im Verein! 


Auszug aus den Computersystemen 


Commodore 


AMSTRAD 


sinclair! 


Alte Computersysteme abzugeben? 
Wir sammeln und erhalten 


In lereinstorun diskutieren Hir über 
dies Und d33, helfen bei Rechner-Prob- 
lenen und haben eine gute Zeit! 


Hardware 


Commodores unbekannter Rechner 


Die Commodore 


MAX Machine 


Seit vielen Jahren gilt sie als Rarität, denn nur eine ge- 
ringe fünfstellige Anzahl wurde von ihr verkauft. Heute 
existieren daher entsprechend wenig Exemplare. 


Für gut erhaltene Stücke, am besten mit 

] vollständigem Zubehör und in Original- 
verpackung, zahlen Sammler derzeit 
zwischen 500 und 800 €. Die Rede ist von 
der Commodore Max Machine, die dieses 
Jahr ihren 40. Geburtstag feiert. Wer noch 
nie etwas von diesem geheimnisvollen 
Kleinod aus Commodores Produktportfolio 
gehört hat, braucht sich nicht wundern, 
denn dieses Gerät wurde nicht in Europa 
oder den USA verkauft. Einzig in Japan, wo 
der Rechner vom Commodore-Ingenieur 
Yashi Terakura entwickelt wurde, war das 
Gerät für ein knappes Jahr erhältlich. Die 
Markteinführung erfolgte Anfang 1982. 
Trotz des vergleichsweise niedrigen Ver- 
kaufspreises von 34.800 Yen (1982 ca. 340 
DM oder 140 US-Dollar) hatte der Rech- 
ner leider keinen kommerziellen 
Erfolg. Er floppte grandios, denn 
der japanische Heimcomputer- 
Markt war 1982 stark von japani- 
schen Spielekonsolen dominiert. 
Und obwohl die Max Machine eine 
vollwertige Konsole ist, hatte Com- 
modore als US-Hersteller hier von 
Anfang an einen schweren Stand. 
Die Geräte blieben in den Regalen 
liegen und die spätere Markteinfüh- 
rung in den USA und in Europa wurde 
abgeblasen. Als Zeugnisse dieser Zeit 
sind noch Werbeanzeigen erhalten, die 
den VC10, wie die Max Machine in 
Deutschland heißen sollte, bewarben. 
Nur erreichten die angekündigten Geräte 
niemals die deutschen Geschäfte. Statt- 
dessen startete bei uns das Weihnachts- 
geschäft 1982 gleich mit dem Commodore 
64 als neuem Heimcomputer-Flaggschiff. 

Welche Geheimnisse stecken also in die- 
sem Rechner, den Commodore Anfang 
1982 in Japan im Spielekonsolen-Markt so- 
wie als preisgünstige Alternative zum Com- 
modore VC20 und in Konkurrenz zu 
Billig-Rechnern wie dem Sinclair ZX81 po- 
sitionierte? Erscheinen sie heutzutage na- 
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hezu lächerlich, so waren im Erschei- 
nungsjahr 1982 die technischen Werte der 
Max Machine für das angepeilte Niedrig- 
preissegment durchaus zeitgemäß: 2,5 kB 
RAM und dazu eine farbige Grafikausga- 
be durch den Grafikchip MOS6566. Dieser 
ist bis auf das Memory-Interface identisch 
zum kurz danach im Commodore 64 ver- 
bauten VIC-II Grafikchip. Ebenso feierte 
der legendäre Synthesizer Chip MOS6581, 
auch als SID bekannt, in der Max Machine 
seine Premiere und nicht etwa im etwas 
später erschienenen Commodore 

64. Diese Tatsache ist heu- 
te selbst 


einge- 
fleischten SID-Fans 
kaum bewusst. Hinzu ge- 
sellt sich ein MOS6526 für die Ab- 
frage von Joystick und Tastatur und 
natürlich der Prozessor MOS6510, der mit 
1 Mhz getaktet ist. Das RAM besteht aus 
einem 2 kByte SRAM und 0,5 kByte Farb- 
RAM. Eine PLA für die Adressdekodierung 
trägt die Bezeichnung MOS6703. Ein ROM 
ist nicht vorhanden. Aus technischer Sicht 
kann die Max Machine als Vorgänger des 
später erschienenen Commodore 64 ge- 
sehen werden. Sie ähnelt diesem in vielen 
technischen Details, wenn auch einige Din- 
ge fehlen, wie beispielsweise der An- 
schluss für ein Diskettenlaufwerk. 
An Anschlüssen bietet die Max Machine 


zwei Joystick-Ports und einen Antennen- 
ausgang für den Anschluss an einen Fern- 
seher sowie einen separaten Audio-Aus- 
gang in Form einer 3,5 mm Klinkenbuchse. 
Im Gegensatz zur Konsolen-Konkurrenz ist 
aber auch ein Kassettenport vorhanden. 
Eine dort angeschlossene Datasette dient 
aber eher als Datenspeicher für die weni- 
gen ernsthaften Anwendungen wie bei- 
spielweise dem “Music Composer” denn 
als Quelle für Software. Spiele und ande- 
re Software wurden ausschließlich über 
Module ausgeführt, wie bei seinerzeit gän- 
gigen Konsolen auch. Dennoch macht der 
Datasetten-Anschluss und die eingebaute 
Folientastatur die Max Machine zu einem 
für damalige Verhältnisse vollwertigen 
Heimcomputer. Das hierfür unabding- ba- 
re Basic gibt es gleich in zwei Versionen, 
natürlich jeweils als Modul. 
Das Mini-BASIC Modul bietet, im 
Vergleich zur Basic 2.0 Version des 
PET oder des VC20, einen re- 
duzierten Funktionsumfang. 
So fehlen beispielsweise 
sämtliche Befehle zum 
Laden und Speichern 
auf der Datasette. Auch 
ist der verfügbare Pro- 
grammspeicherplatz mit 
nur 510 Bytes sehr klein 
geraten. Daher ist diese BASIC- 
Version mehr ein Spielzeug als eine 
wirklich sinnvolle Anwendung, zumal ein- 
gegebene Programme sich nicht einmal 
abspeichern lassen und jedes Mal frisch 
eingetippt werden müssen. 

Die zweite BASIC-Version erschien auf 
dem Max-BASIC-Modul. Diese Version 
enthält den kompletten BASIC 2.0 Befehls- 
umfang, kann also auch die Datasette an- 
sprechen. Programme können geschrie- 
ben, mit der Datasette abgespeichert und 
später wieder geladen werden. Dank einer 
im Modul eingebauten 2k RAM-Erweiter- 
ung, ist bei diesem Basic immerhin 2047 
Byte Programmspeicher verfügbar. Dies ist 
in etwa die Hälfte dessen, was der Vorgän- 
ger VC20 bietet und somit immer noch nicht 
besonders großzügig bemessen. Der 
knappe Speicherausbau war offensichtlich 
vorwiegend dem Wunsch nach einem nie- 


Bild: Thomas Hechelhammer aus http://www. zimmers.net/anonftp/pub/cbm/c64/html/ultimax.html 
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Oben: Die Hauptplatine der Max Machine 
Unten: Die Anschlüsse auf der Rückseite 


drigen Verkaufspreis geschuldet: Der 
MOS6566 VIC-II-Chip ist nicht in der Lage, 
den Refresh für kostengünstige dynami- 
sche DRAM-Bausteine zu erledigen. Da- 
durch war man, wie auch beim VC20, auf 
teures statisches SRAM angewiesen. Also 
wurde aus Kostengründen wohl so wenig 
wie möglich davon verbaut. Es soll dem Ver- 
nehmen nach bei Commodore heftige Dis- 
kussionen darüber gegeben haben, denn 
mit dem niedrigen Speicherausbau war der 
neue VIC-II-Chip nicht einmal mehr in der 
Lage, ein Bitmap-Bild im Speicher anzuzei- 
gen. Doch am Ende setzte sich Commodo- 


Die „Neuen” von 


z commodore 


Voraussichtlich ab Oktober 1982 lieferbar! 


Commodore VC 10 Der Kleine mit der großen Leistung ! 


Der neue Commodore VC 10 ist ein Video-Spiel-Computer „mit Intelli- 
genz"-für Heim und Hobby, Unterricht und Ausbildung, an jedes (Farb-) 
Fernsehgerät anschließbar. Der Commodore VC 10 ist der erste Video- 
Computer, der nicht nur zum Spielen geeignet ist, sondern frei program- 
mierbar (in Mini-Basic) auch anderen Anwendungen offen steht. 

Technische Daten: Speicherkapazität: 2,5 kByte RAM frei verfügbar - 
Programmiersprache: Mini-Basic : Zeichen, Zeilen: 40 Zeichen/Zeile, 
25 Zeilen - Tastatur: großes Membran-Tastenfeld - Grafik: hochauflö- 
sende Farbgrafik - Sonstiges: Musiksynthesizer, an Lichtschreiber und 
Joystick anschließbar, Steckmodultechnik, Audio-Ausgang, an jedes 


Fernsehgerät anschließbar. 
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re-Chef Jack Tramiel durch und verlangte, 
den Speicher und damit die Kosten zu re- 
duzieren. Erst mit der Weiterentwicklung 
des VIC-II- Chips zum MOS6567 konnte 
dann DRAM verwendet werden, was erst- 
mals im Nachfolger Commodore 64 zum 
Einsatz kam. Von der Max Machine erbte 
dieser auch einen speziellen “Ultimax”-Mo- 
dus, der sich über eine besondere Signal- 
kombination am Expansionport freischalten 
lässt. In diesem Modus ist der Commodo- 
re 64 weitgehend kompatibel zur Max Ma- 
chine, sodass sich sämtliche existierenden 
Module für die Max Machine auch am Com- 
modore 64 verwenden 
lassen. Und das sind, 
gemessen an der kurz- 
en Marktpräsenz des 
Geräts, doch einige. 

Etwa 20 Spiele und 
einige Anwendungen, 
vor allem aus dem Bil- 
dungsbereich, sorgten 
für Abwechslung. Viele 
der Module sind später 
auch fast unverändert 
für den Commodore 64 
verkauft worden. Einige 
Spiele gelten bis heute 
als Klassiker: Commo- 
dores “Jupiter Lander”, 
“Radar Rat Race”, “Wi- 
zard of Wor” oder auch 
“Pinball” gab es für die 
Max Machine — diese 
Spiele sind bis heute 
unvergessen! 

Heute finden sich 
sämtliche für die Max 
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Ankündigung des VC10 von 1982 


Stück 498.- Machine erschienenen 


Module versammelt in 


Ein Rechner, viele Namen 


Die “Max Machine” wurde streng genommen nur in 
Japan so genannt. Für die USA war zunächst der Name 
“Ultimax” vorgesehen. Gerüchten zufolge soll dies aber 
zu sehr nach Hygieneprodukten geklungen haben, so 
dass man sich später auf “VIC-10” festlegte. Analog 
sollte das Gerät in Europa dann “VC10" heißen. Andere 
Namen sind “Commodore Max” und das eher liebevolle 
“Vicky”, wie der Rechner bei seiner ersten Vorstellung 
in Tokyo genannt wurde. 


dem 2014 erschienenen Multimax-Modul. 
Von einigen Spielen sind sogar mehrere 
Versionen abrufbar, die unter anderem zei- 
gen, wie viel beziehungsweise wenig Än- 
derungen Commodore bei einer späteren 
Commodore 64-Version vorgenommen hat. 
Da dieses Modul auch mit einem Commo- 
dore 64 funktioniert, bietet es einen inter- 
essanten Einblick in die Welt der Max 
Machine - auch für diejenigen, die nicht das 
Glück haben, eine solche zu besitzen (ab). 


Links 


C64-Wiki: 
https://www.c64-wiki.de/wiki/Max_Machine 
Wikipedia: 

https://de.wikipedia.org/wiki/ 
Commodore_Max, 

Wikipedia (japanisch): 
https://ja.wikipedia.org/wiki/%E3%83%I9E 
HEIHEIHEIKHEIHELHAFHEIHE2 BI 
HEIHEIHIEHEIHE2LUBTHEIHEIHBC 
HE3IHEIHBI 

Secret Weapons of Commodore: 
http.://wwu.floodgap.com/retrobits/ckb/ 
secret/ultimax.html 

Japanese vintage Computer Collection: 
https://monochromeeffect.org/JVCC/201%/ 
07/31/commodore-max-machine/ 

Michael Steil: 
https://www.pagetable.com/?p=1158 

The Future was 8 Bit: 
https:/wwu.thefuturewasö8bit.com/ 
maxmachine 

Multimax Modul: 

http://www.multimax.co/ 

Technische Infos: 
http://www.zimmers.net/anonftp/pub/ 
cbm/ c64/html/ultimax.htmi 


Ueber den Autor 


Andreas Beermann, Jahrgang 
1969, ist Diplom-Ingenieur in 
der Halbleiter-Industrie und 
seit 2011 Mitglied im VzEkC 
e.V. Seinen ersten Commodore 
64 kaufte er mit 14 Jahren. 
Schnell wurde daran kraeftig 
programmiert und geloetet, um 
die verborgenen Geheimnisse 
zu entdecken. 


Hardware 


Commodore Max Machine wiederbeleben 


Right to Repair 


Nicht immer funktioniert ein Sammlerstück gleich auf Anhieb. 
Wenn es sich dabei noch um ein seltenes Gerät handelt, 
kann die Reparatur voll Tücke sein. Vereinsmitglied Andreas 
Beermann berichtet von seinen Erlebnissen mit einer 


Commodore Max Machine. 


Einsam, von ihrem Original-Zubehör ver- 
lassen, ein bisschen schmutzig und leider 
auch defekt, so lag sie eines Tages vor mir: 
eine Commodore Max Machine. Ein be- 
freundeter Sammler japanischer Heimcom- 
puter hatte sie an mich weitergegeben. Er 
fand, dass dieses Gerät eines US-Her- 
stellers nicht so recht zu seiner Sammlung 
passen würde. Er hatte es mehr oder weni- 
ger zufällig ergattert, als er die Webseite 
buyee.jp testen wollte. Über den Service 
dieser Seite ist die Teilnahme von Europa 
aus an japanischen Online-Auktionen mög- 
lich, beispielsweise an den in Japan sehr 
beliebten Yahoo-Auctions. Als ersten Test 
gab er das Mindestgebot für eine zufällig 
gerade zur Auktion gelistete Max Machine 
ab. Sie wurde ohne Netzteil, Verpackung 
und weiteres Zubehör sowie als defekt an- 
geboten. Solche unvollständigen und de- 
fekten Geräte haben in japanischen Auk- 
tionen kaum eine Chance. So geschah es, 
dass er wider Erwarten mit seinem Erstge- 
bot sogleich den Zuschlag erhielt. Der 
Versand nach Europa dauerte sehr lange, 
auch weil buyee.jp mehrere Käufe bündelt 
und erst bei einem ausreichend großen 


Die S-Video-Modifikation (grün/gelb), hier noch ergänzt um 


Composite Video (weiß) und Audio (rot) 
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Versandvolumen die Ware verschickt. 
Doch was sind ein paar Monate Lieferzeit 
bei einem Gerät, das seit 40 Jahren darauf 
hofft, eines Tages in gute Sammlerhände 
zu geraten, um so der Verschrottung zu 
entgehen? 

Natürlich konnte ich diesen aufregenden 
Neuzugang für meine Sammlung nicht in 
seinem bemitleidenswerten Zustand be- 
lassen. Also ging es darum, das Gerät 
wiederzubeleben. Zunächst zerlegte ich 
die Max Machine so weit, dass ich alle 
nicht-elektronischen Teile in warmem Sei- 
fenwasser spülen konnte. Die Tastatur 
wollte ich zunächst auch nass reinigen. Al- 
lerdings merkte ich schnell, dass die 
Folientasten offensichtlich auf einer saug- 
fähigen Pappschicht angebracht sind. So 
wischte ich die Tastatur nur feucht ab, um 
sie gleich danach wieder gut zu trocknen. 
Bei der Reinigungsaktion fiel auch auf, 
dass einer der Gummifüße am Gerät fehlte. 
Zum Glück hatte ich noch nahezu iden- 
tischen Ersatz in Form von selbstkleben- 
den Gehäusefüßen aus dem Elektronik- 
handel vorrätig. 


€ 


Die Stromversorgung des Gerätes stell- 
te, trotz des fehlenden Netzteils, kein gro- 
Res Hindernis dar: Die Max Machine be- 
nötigt dasselbe Netzgerät wie auch der 
Commodore 64. So konnte ich eines der 
zahlreich vorhandenen Geräte verwenden. 
Das hatte zugleich den Vorteil, dass es sich 
mit der in Deutschland üblichen Netzspan- 
nung betreiben lässt. Japanische Geräte 
sind für eine Netzspannung von nur 100 V 
ausgelegt, was am europäischen 230V- 
Stromnetz zwingend einen entsprech- 
enden Vorschalttransformator voraussetzt. 

Nachdem die Stromversorgung gesich- 
ert war, musste als nächstes der Videoaus- 
gang enträtselt werden. Die Max Machine 
verfügt nur über einen HF-Modulator-Aus- 
gang. Aufgrund der japanischen Herkunft 
darf vermutet werden, dass hier ein japa- 
nisches NTSC-J Antennensignal anliegt. 
Ein Schalter am Modulator erlaubt die Aus- 
wahl von Kanal 1 oder 2. Im japanischen 
Kanalraster liegen diese Kanäle im Fre- 
quenzbereich von 90 MHz bis 102 MHz. 
Auf diesen Frequenzen liegt hierzulande 
aber der Bereich für das UKW-Radio. So 
hatte ich keine Hoffnung, mit meinem 
europäi- schen Fernsehgerät dieses Sig- 
nal zu empfangen. Also musste eine an- 
dere Lösung her. 

Im Netz kursiert der sogenannte One- 
Wire-Mod für die Max Machine. Bei dieser 
Modifikation wird eine Drahtverbindung 
vom Modulator auf die eigentlich für das 
Audiosignal gedachte 3,5mm Klinken- 


Das Netzteil eines Commodore 64 passt auch an die Max Machine. 


Das selbst gebaute Steckmodul, mit 
Lötbrücke zwischen den Kontakten “EXR” 
und “IO2”, liefert erstes Futter für die Max 
Machine. 


buchse gelegt. Auf diese Weise liegt an der 
Buchse zusätzlich zum Audiosignal auch 
ein Composite-Video-Signal an. Mit einem 
entsprechenden Adapterkabel (3,5 mm 
Stereo-Klinke auf 2x Cinch) lässt sich so 
bequem das Videosignal von außen ab- 
greifen, ohne dass zusätzliche Buchsen 
am Gehäuse angebracht werden müssen. 
So elegant diese Modifikation auch ist, so 
bescheiden ist leider die damit zu erzie- 
lende Bildqualität. Auch die Tonqualität 
leidet unter dem Übersprechen des Video- 
signals in das Audiosignal. 

Also entschied ich mich für eine bessere 
Lösung: Ein S-Video-Kabel wird auf einer 
Seite von seinem Stecker befreit und direkt 
an die entsprechenden Pins des Modula- 
tors auf der Unterseite der Hauptplatine 
gelötet. Das Kabel muss dann durch eine 
Gehäuseöffnung, also z.B. durch den Kas- 
settenport, nach außen geführt werden. 
Der Anschluss erfolgt schließlich an der S- 
Video-Buchse des Fernsehers. Dieser soll- 
te NTSC-tauglich sein, damit das Bild far- 
big dargestellt wird. Die so erzielte Bild- 
qualität ist hervorragend, deutlich besser 
als über den HF-Modulator-Ausgang, was 
ich nach Fertigstellung dieser Modifikation 
feststellen durfte: Viel zu spät entdeckte 
ich, dass sich mein Fernsehgerät per 
Ländereinstellung auf “Japan” stellen lässt. 
Damit ist es dann eben doch in der Lage, 
das HF-Signal der Max Machine zu em- 
pfangen. Dieser Fehler wäre einem er- 
fahrenen Samnler japanischer Rechner 
wohl nicht passiert. 

Wie dem auch sei, leider lieferte meine 
Max Machine auch mit diesem Kabel zu- 
nächst noch kein Bild. Bei der Fehlersuche 
wurde mir erst nach einem Blick in den im 
Netz verfügbaren Schaltplan klar, dass das 
Gerät über keinerlei eingebautes ROM ver- 
fügt. Ohne Steckmodul würde die Max Ma- 
chine also folglich — wie zu erwarten — 
keinen Mucks von sich geben. Also musste 
ein geeignetes Steckmodul her. Auf die 
Schnelle ging das nur, indem ich auf Basis 
einer Prototypen-Platine für den mecha- 
nisch kompatiblen Expansionsport des 


Commodore 64 ein ROM-Modul selbst 
baute. Das auf dem Modul verwendete 
EPROM hatte Platz für vier der einfacher- 
en Multimax-Spiele und ich entschied mich 
für “Radar Rat Race”, “Omega Race”, 
“Clowns” und aus Gründen des leichteren 
Debuggens noch “Mini-Basic”. Die Pro- 
gramme ließen sich jeweils über Steck- 
jumper auswählen. Mit diesem Modul 
gelang es mir dann zum ersten Mal, der 
Max Machine ein Bild zu entlocken. 

Doch die Freude währte nicht lange. 
Weder Tastatur noch Joysticks schienen 
zu funktionieren. Der Verdacht fiel sofort 
auf den CIA MOS6526, der in der Max Ma- 
chine für die Tastatur- und Joystick-Abfrage 
zuständig ist. Tauschen gegen einen funk- 
tionierenden CIA brachte aber keinen Er- 
folg. Der Test des ClA aus der Max Machine 
in einem Commodore 64 ergab, dass der 
Baustein noch funktionierte. Erst nach 
längerem Suchen im Schaltplan bemerkte 
ich, dass das Chip-Select-Signal des CIA 
bei der Max Machine über zwei Pins am 
Expansionport geschleift wird: Eine Pin- 
belegung, die sich vom Commodore 64 un- 
terscheidet und daher von mir zunächst 
nicht bedacht wurde. Auf meinem selbst 
gebauten Modul half nun eine Lötbrücke 
zwischen den Pins EXROM und IO2, um 
das Signal entsprechend zu verbinden. 
Kaum war diese vorhanden, nahm der CIA 
seine Funktion auf und die Joysticks funk- 
tionierten nun. Mit der Tastatur gab es al- 
lerdings immer noch ein Problem, denn 
einige Tasten streikten weiterhin. Ein Ver- 
folgen der Leiterbahnen auf dem Folien- 
leiter der Tastatur ergab eine Uhnter- 
brechung in einer Leiterbahn. Diese war 
leicht mit etwas Leitsilber zu reparieren. 
Danach war nun auch die Tastatur funk- 
tional. 

Doch das war immer noch nicht das 
Ende des Reparaturmarathons. Als ich die 
Spiele auf meinem Selfmade-Modul aus- 
probierte, war kein Ton zu hören. Weder 


über die 3,5 mm Klinkenbuchse, noch über 
das von mir gleichzeitig mit dem S-Video- 
Kabel direkt angelötete Audiokabel kam 
ein Signal. Durch Tausch wurde schnell 
klar, dass der MOS6581 SID defekt war. 
Ersatz wurde zunächst durch einen ohne- 
hin vorhandenen FPGASID bereitgestellt. 
Aus Gründen der Originalität kam jedoch 
später dann ein originaler SID zum Einsatz, 
mit einem Datums-Code passend zum de- 
fekten SID. 

Nach dieser doch etwas längeren Repa- 
ratur ist die Max Machine nun endlich wie- 
der vollständig funktionsfähig. Einzig das 
aus dem Gehäuse baumelnde Video-Ka- 
bel stört ein bisschen die Optik. Womög- 
lich sollte ich dies aus Gründen der Origi- 
nalität doch wieder entfernen und das 
Gerät ausschließlich über den HF-Modu- 
lator betreiben. Auch sind einige Blechteile 
im Inneren des Gerätes etwas korrodiert, 
was sich ebenfalls noch verbessern ließe. 
Aber ein bisschen sollte man dem Gerät 
sein Alter ja auch ansehen und so werde 
ich die Korrosion zwar weiter beobachten, 
aber im Moment noch nicht beheben (ab). 


Links 


Scan des Schaltplans (kaum lesbar): 
http://www.zimmers.net/anonftp/pub/cbm/ 
schematics/computers/c64/326100.png 
Schaltplan reverse engineered von Dona- 
to Travaglini (leider in Teilen fehlerhaft): 
http://www.zimmers.net/anonftp/pub/cbm/ 
schematics/computers/c64/ 
maxschematic.jpg 

Schaltplan von Ruud Baltissen (entspricht 
nicht meiner Platinen-Revision) 
http:/www.zimmers.net/anonftp/pub/cbm/ 
schematics/computers/c64/ultimax.gif 
Der One-Wire-Mod: 
http://www.6502.org/users/sjgray/ 
projects/maxvid/index.html 

Einkaufen in Japan: 

https://buyee.jp 

Online-Auktionen in Japan: 
https://auctions.yahoo.co.jp 


Der Lohn der Mühen — die Max Machine in Aktion! 


Hardware 


PC Emulatoren für Apple Macintosh 


Einen DOS-Mac, bitte! 


Wie bei allen anderen Hardware-Emulatoren für Computer 
wie dem Atari ST oder Commodore Amiga steht auch 

beim Macintosh am Anfang die Frage: „Warum muss der 
Mac PC kompatibel werden?“. Wir versuchen, eine Antwort 


zu geben. 


Mehr noch als bei den anderen beiden 
beschriebenen Plattformen haben sich die 
Rechner aus Cupertino seit dem Ende der 
1970er Jahre sehr gut verkauft. Sie haben 
mit ihrer Softwareausstattung wie beispiels- 
weise Visicalc und AppleWorks selbst Maß- 
stäbe gesetzt. Allerdings entstand beim 
Wechsel auf die 68k-Plattform eine immer 
größer werdende Lücke zur IBM-kompati- 
blen Welt, die irgendwie gefüllt werden 
musste. 


MacCharlie 


Bereits im Jahr 1985 entwickelte die Fir- 
ma Dayna Communications einen PC- 
Emulator, den MacCharlie. Ähnlich wie das 
Commodore A1060 Pendant wird dieser 
seitlich an den Macintosh 128k, 512k oder 
Plus angeflanscht. Die externe Box enthält 
eine komplette PC-Hardware inklusive der 
Intel 8088 CPU mit einer Taktfrequenz von 
4,77 MHz, 256 KByte bis 640 KByte RAM 
und ein 5,25°-DD-Laufwerk mit einer Spei- 
cherkapazität von 360 KByte. Die Kommu- 
nikation zwischen beiden Plattformen 
erfolgt über zwei 9-polige Anschlüsse des 
MacCharlie an den Drucker- und Modem- 
anschluss des Mac. Der Mac dient so als 
Konsole für den PC-Teil, lauffähig sind al- 
so nur textbasierte DOS-Programme. Dar- 
über hinaus konnten auch Dateien zwi- 
schen den beiden Welten ausgetauscht 
und die beiden getrennten Echtzeituhren 
synchronisiert werden. Da das Keyboard 
der 128k-, 512k- und Plus-Macs nicht alle 
Tasten zur Verfügung stellt, lieferte Dayna 
einen Keyboard-Extender mit, der die Funk- 
tionstasten sowie den Ziffernblock bereit- 
stellt. Das System ist zum einen recht 
langsam, zum anderen war es aber auch 
recht teuer und fand folglich keine große 
Verbreitung. 
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Mac SE und Mac II 
mit DOS-Füllung 


1987 stellte Apple die ersten intern er- 
weiterbaren Modelle Macintosh SE und 
Macintosh Il vor. In Zusammenarbeit mit 
Apple entwickelte Phoenix Technologies in 
der Folgezeit zwei PC-Emulatoren, die von 
der Firma AST Research ab 1988 vermark- 
tet wurden. Für den Macintosh SE entstand 
so die Mac86-Erweiterung für den Proces- 
sor Direct Slot (PDS). Die Karte hat einen 
8086-Prozessor mit 7,86 MHz, bringt aber 
keinen eigenen Speicher mit. Die RAM- 
Größe wurde über die Application Size im 
Finder eingestellt. Die Maximalkonfigurati- 
on von 640 KByte für MS-DOS erfordert 
dort einen Wert von 1.300 KByte. 

Das interne Diskettenlaufwerk des Mac 
ist nicht direkt zu nutzen, deshalb wird zwin- 
gend ein passendes externes Disketten- 
laufwerk für den 37-poligen Anschluss 
benötigt. Bei Installation der mitgelieferten 
Software wird eine 10 MByte große Datei 
als Festplattendatei (Hardfile) mit MS-DOS 
3.2 angelegt. Wie auch der MacCharlie hat 
auch die Mac86 keine Grafikausgabe, ist 
also auf textbasierte DOS-Programme be- 
schränkt. Die Konsole wird direkt im Mac 
OS als Fenster eingeblendet und bietet 
80x25 Zeichen. 

Unter MS-DOS funktioniert die Maus und 
auch ein Zugriff auf den Mac-Lautsprecher 
klappt. Um serielle Geräte unter MS-DOS 
nutzen zu können, gibt es zwei emulierte 
serielle Schnittstellen (COM1 und COM2), 
die entweder auf den Drucker- oder den 
Modemanschluss umgeleitet werden kön- 
nen. 

Anders gestrickt war die Mac286 des 
gleichen Herstellers. Hierbei handelt es 
sich um eine Steckkarte für den Nubus-Er- 
weiterungssteckplatz, der ab dem Macin- 
tosh II über viele Jahre von Apple ver- 
wendet wurde. Auch bei dieser Karte finden 
sich erstaunliche Ähnlichkeiten zur Amiga- 


MacCharlie am Macintosh 


Parallelwelt. Auch die Mac286 ist wie die 
Commodore A2286 eine Karte mit zwei 
Platinen, diese sind allerdings mit zwei Ka- 
beln verbunden. Auch die AST nutzt einen 
Intel 80286 mit 8 MHz Takt, hat 1 MByte 
RAM auf der Karte und kennt die Möglich- 
keit, eine FPU einzusetzen. Obwohl durch 
SIMMs realisiert, lässt sich der Arbeitsspei- 
cher bei der originalen Karte von AST nicht 
auf 4 MByte erweitern. Als weitere Verbes- 
serung kann entweder das Laufwerk des 
Host-Macs oder aber (wie bei der Mac86) 
ein externes Laufwerk über den 37-poligen 
Anschluss als Laufwerk A: konfiguriert wer- 
den. Dabei kommt ein NEC 765 basierter 
Floppy-Controller zum Einsatz. Im Gegen- 
satz zu den meisten PCs akzeptiert das 
Laufwerk mit entsprechenden Tools auch 
Single Density-Disketten aus der CP/M- 
Welt. Beim Installationsvorgang wird ein 
20 MByte großes Hardfile als Festplatte für 
die PC-Karte angelegt, MS-DOS 3.30 ist 
darauf vorinstalliert. Diese Karte macht es 
auch möglich, endlich graphische Anwen- 
dungen auf der Emulation zu nutzen, denn 
sie bietet neben dem Textmodus auch ei- 
ne CGA-Emulation an. Die weiteren Ein- 
stellungsmöglichkeiten sind mit der Mac86 
vergleichbar. Auch die Bildschirmdarstel- 
lung ist als reiner Bild-im-Bild-Modus rea- 
lisiert. AST Research zog sich 1989 aus 
dem Apple- Geschäft zurück und verkauf- 


Der AST Mac286-Emulator 
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Orange Micro Karten 


Serie 200 

Orange Micro fertigte vier verschiedene 
Modelle dieser Baureihe. Die einfachste 
Variante ist die OrangePC 210, die mit ein- 
er Standard-VGA-Grafik sowie serieller und 
paralleler Schnittstelle am Expansionskabel 
ausgeliefert wurde. Die OrangePC 220 
bietet darüber hinaus auch SVGA-Grafik, 
ebenso wie die folgenden Modelle. Auf dem 
Modell OrangePC 250 ist ein PCMCIA Slot 
(CL-PD6710) verbaut, um so zum Beispiel 
Netzwerk- oder Soundkarten nutzen zu 
können. Dafür wurde aber auf die serielle 
und parallele Schnittstelle verzichtet. Das 
Top-Modell OrangePC 290 beinhaltet neben 
dem PCMCIA Interface auch wieder diese 
beiden Schnittstellen und zusätzlich 128 
KByte 20-ns-Cache für die CPU. 


Serie 300 

Während die Nubus-Karte 340 die finale En- 
twicklungsstufe der OrangePC-Karten für die 
Nubus-Macs darstellt, waren die beiden PCI- 
Karten 420 und 440 die ersten PC-Emu- 
latoren von Orange für den neuen Erweiter- 
ungsbus in den Power Macs. Soweit es in 


Erfahrung zu bringen war, gibt es kein 
Nubus-Pendant zur OrangePC 420. Diese 
Version bietet neben einer 1 MByte 
Grafiklösung (S3 Trio64) einen Speicher- 
sockel für PS/2-DIMMs mit maximal 32 
MByte Arbeitsspeicher. Eine CPU-Cache ist 
bei der „kleinen“ neuen PCI-Karte nicht 
verbaut. Die Nubus 340 und die PCI 440 er- 
möglichen es dem Nutzer, den Grafikspeich- 
er auf 2 MByte aufzurüsten. Sie stellen zwei 
PS/2-Slots für bis zu 64 MByte RAM zur 
Verfügung. Beide Karten sind mit 256 KByte 
Cache (20ns) für die CPU ausgestattet. Das 
Modell 340 kommt mit 3,3 V und 5 V 80486 
CPUs wie den DX2- und DX4-CPUs, aber 
auch dem Cyrix 5x86 zurecht. Für die 
beiden 400er Boards findet sich auf der Liste 
der unterstützten CPUs nur der Cyrix DX2- 
80 sowie der Cyrix 5x86mit 120 MHz. Dies 
mag daran liegen, dass die 400er Boards 
den FSB der Karte mit 40 MHz takten. Für 
die nun endlich implementierte Sound- 
Blaster-kompatible Tonausgabe sorgt ein 
Chip von ESS. 


Serie 500 
Bei der Orange PC 520 ist eine 1 MByte 
Grafikkarte (S3 Trio64V+), erweiterbar auf 


2 MByte verbaut, sie wurde häufig mit einer 
Cyrix 686+ CPU mit 166 MHz angeboten. 
Die 530 hat bereits 2 MByte Grafikspeicher 
verlötet und benötigt nicht den vorgenan- 
nten Zwischensockel für MMX-CPUs. Der 
Arbeitsspeicher ist bei beiden 7“-Karten 
durch einen EDO-DIMM (5V) mit bis zu 128 
MByte realisiert, ein Cache-RAM für die 
CPU ist nicht vorgesehen. 


Die OrangePC 540 als erstes 12°-Modell 
dieser Reihe hat eine 2 MByte Grafikkarte 
(S3Trio 64V+), zwei DIMM-Steckplätze für 
bis zu 256 MByte EDO-RAM sowie 256 
KByte Cache-RAM, um die CPU zu 
beschleunigen. Bei den drei bisher genan- 
nten Modellen ist eine 16-bit SoundBlaster- 
kompatible Audiolösung (ESS-Chip) 
verbaut. Bei der 550, der Top-Karte aus der 
500er Serie, änderte Orange Micro so ein- 
iges: Der Hersteller stieg auf den S3-Virge 
Grafikchip um und spendierte diesem 4 
MByte SG-RAM. Darüber hinaus wurde der 
Cache-RAM auf 512 KByte erweitert und 
der verwendete ESS-Audiochip bot 3D-Ef- 
fekte und Wavetable. 


Serie 600 

Die 620 hat einen SIS 5598-Chipsatz mit in- 
tegrierter Grafik, die neben 2D-Beschleuni- 
gung zumindest eine 3D-Emulation anbietet. 
Da der Chipsatz nur mit einen FSB bis 75 
MHz (mit Übertaktung 83 MHz) arbeitet, 
sind bei diesen Karten alle CPUs mit 100 
MHz FSB nicht verwendbar. Auch auf einen 
2nd-Level-Cache wurde verzichtet. Laut 
Handbuch von Orange Micro war keine In- 
stallation von Windows NT möglich, ganz im 
Gegensatz zu den anderen PCI-Karten. 


Das mit Abstand leistungsfähigste Modell ist 
die Ende 1998 eingeführte OrangePC 660. 
Mit ihrem VIA VT82C598-Chipsatz ermög- 
licht sie den Einsatz quasi aller Sockel7- 
CPUs bis zu 450 MHz und die Verwendung 
von zwei SD-RAM Modulen für einen maxi- 
malen Speicherausbau von 256 MB. Das 
große Highlight dieser Karte ist aber der 
Grafikchip nVidia Riva 128 mit 4 MByte SG- 
RAM. Kein Wunder, dass sie als Spiele- 
Lösung für den Mac vermarktet wurde. Die 
PCfx, auch 650 genannt, ist eine verein- 
fachte 660 mit einem RAM-Slot und wurde h 
mit einer nicht austauschbaren Pentium 
kompatiblen CPU (möglicherweise IDT Win- 


te seine Rechte und technischen Unterla- 
gen über die beiden PC-Karten an Orange 
Micro. 


DOS-Mac mit Orangenaroma 


Nach der Übernahme entwickelte Oran- 
ge Micro die Mac286 weiter und ermöglich- 
te als erstes die Verwendung von 1 MByte 
SIMMs, so dass ein Speicherausbau von 
insgesamt 4 MByte möglich wurde. In der 
finalen Weiterentwicklung wurde die Mac- 
286 auf eine Steckkarte reduziert. Die Kar- 
ten laufen mit Taktfrequenzen von 12 und 
16 MHz. Inzwischen vollzog sich in der IBM 
PC-Welt der Wechsel von den 80286er PCs 
hin zu den Maschinen mit Intel 80386. Auch 
Orange Micro entwickelte daraufhin seine 
PC-Karte weiter und präsentierte die Oran- 
ge3886. Bereits die erste Version hat zwei 
ISA-Slots (einmal 8 Bit, einmal 16 Bit) und 
ermöglicht einen Speicherausbau mit vier 
30-poligen SIMM- Modulen auf maximal 
16 MByte. Die 386SX-CPU ist mit 16 oder 
25 MHz getaktet. Ohne Grafikkarte in ei- 
nem der ISA-Slots bietet die Karte nur die 
bekannte langsame CGA-Emulation. Über 
den optionalen externen Anschluss stellt 
die erste Version des sogenannten Okto- 
pus-Kabels einen Anschluss an die seriel- 
le und parallele Schnittstelle sowie den 
Floppy-Port bereit. 

Auch Orange Micro verstand, dass die- 
se Karte nur mit einer VGA-Karte wirklich 
nutzbar ist. Daher wurde bei späteren Mo- 
dellen ein WDC WD90C30 SVGA-Chip in- 
tegriert, im Gegenzug ber einer beiden ISA- 
Slots gestrichen. Die letzte Ausbaustufe 


dieses Modells ist mit dem TI486SLC Pro- 
zessor ausgestattet, der mit 25 MHz läuft 
und Pin-kompatibel zur 386SX CPU ist. 

Nächste Evolutionsstufe für den Nubus- 
Steckplatz sind die OrangePC-Karten der 
200er Serie. Diese bieten nun zusammen 
mit einem OPTI-Chipsatz Platz für leis- 
tungsfähigere 486er CPUs mit 3,3 oder 
5,0 V Spannungsversorgung. Angefangen 
beim 80486 SX-16 bis hin zum 80486 DX4- 
100 läuft auf dieser Karte beinahe jede 
CPU. Die 80486 DX4-100 CPU arbeitet al- 
lerdings nur mit den Kartenmodellen Oran- 
gePC 250 und OrangePC 290 zusammen, 
bei letzterer auch nur nach Modifikation. 
Als Arbeitsspeicher kann ein PS/2- Modul 
mit bis zu 32 MByte verbaut werden, laut 
vorliegendem Handbuch sogar bis 64 
MByte. 

Bei allen vorgestellten Modellen muss 
das Videosignal der PC-Karte immer über 
den Nubus Steckplatz an den Macintosh 
weitergegeben werden. Dieser kann es 
dann am Monitor ausgegeben. Es liegt in 
der Natur der Sache, dass dadurch die Bild- 
ausgabe recht langsam ist und zumindest 
zum Spielen nicht ausreicht. 

Den Wechsel von der Nubus- hin zur PCI- 
Plattform vollzog Orange Micro mit den un- 
gleichen 12*-Zwillingen der Baureihen 300 
und 400 mit VIA 82C496-Chipsatz. Als wei- 
tere Neuerung gegenüber den Nubus-Kar- 
ten der 200er Serie verfügt diese Zwillings- 
serie zum ersten Mal über das sog. Hydra- 
bzw. Oktopus-Kabel, welches zwei seriel- 
le und eine parallele Schnittstelle, einen 
Game- beziehungsweise Midi-Port sowie 
je einen Stereo-Klinkenstecker für Tonein- 


Chip C6 mit 200 MHz) angeboten. 


und -ausgang sowie die Durchschleifmög- 
lichkeit für das Bildsignal zur Verfügung 
stellt. Alle PCI Versionen der OrangePC- 
Karten können keine weiteren PCI-Erwei- 
terungskarten nutzen. 

Die nachfolgende 500er Serie wurde für 
den Intel Pentium und kompatible CPUs 
entworfen und repräsentiert so die erste 
Sockel7-Baureihe. Die externen Schnitt- 
stellen sind wie bei der 300er und 400er 
über das sogenannte Hydra- oder Okto- 
pus-Kabel nach außen geführt. Der Her- 
steller unterscheidet hier zwischen einer 
7‘- und einer 12°-Version. Wie gewohnt ist 
die CPU gesockelt und kann daher leicht 
gegen andere unterstützte CPUs getauscht 
werden, Für die 2,8 V Stromversorgung für 
MMX-CPUs ist bei den Kartenmodelle 520 
und 540 ein Zwischensockel notwendig. 

Die Spitze der PC-Emulatoren im Mac 
bilden definitiv die Karten der 600er Serie 
von Orange Micro für Sockel7-CPUs, die 
im Jahre 1998 vorgestellt wurden. Wie bei 
den vorher genannten 500ern gibt es ein 
7‘-Modell (620/625) und zwei 12“-Modelle 
(PCfx/PCfx 655 bzw. 660/665) wobei die 
Karten mit der 5 am Ende der Modellnum- 
mer für die neuen G3-Power Macs im bun- 
ten Blue-and-White-Tower modifiziert sind 
und ansonsten den Modellen mit der 0 am 
Ende entsprechen. Alle Karten schlucken 
SD-RAM als Arbeitsspeicher und durch die 
umfangreichen Einstellungsmöglichkeiten 
laufen eine große Bandbreite von CPUs, 
angefangen beim Pentium mit 100 MHz bis 
hin zum AMD K6-IIl mit 450 MHz. Orange 
Micro verabschiedete sich bei diesen Mo- 
dellen auch vom Oktopus-Kabel, da die an- 


Übersicht zu den wichtigsten PC-Emulatorkarten für den Macintosh 


Karte CPU ‚Grafik 

AST Mac86 Intel 8086 MDA 

AST Mac286 Intel 80286 MDA/CGA 
Orange Micro OrangePC 386 AMD 803865X WDC WD90C30 
Orange Micro OrangePC 220 AMD 5x86 16 MB | WDC WD90C30 
Orange Micro OrangePC 520 Intel Pentium 64 MB | S3 Trio64V+ 
Orange Micro OrangePC 620 AMD K6-Ill 128 MB | SIS 5598 

Apple Houdini I Intel 4865X 16MB | C&T 

Apple Houdini Il Intel 486DX2 

Apple 7“ 100 MHz Cyrix 5x86 100 MHz 

Apple 12“ 100 MHz Intel Pentium 100 MHz 

Apple 12“ 166-P Intel Pentium 166 MHz 


Alle Geschwindigkeitstests wurden mit PC-Doktor 1.70 durchgeführt 


gebotenen Schnittstellen und die Funktion 
der Soundkarte nun per Software-Emula- 
tion im Mac gelöst wurden. Die seriellen 
und parallelen Ports des Emulators können 
wie schon bei der Mac286 den Modem- 
oder Printer-Port des Macs nutzen. Somit 
bleibt die Möglichkeit, das Videosignal des 
Macs über einen VGA-Ein- und -Ausgang 
durchzuschleifen. 

Bei den letzten OrangePC Nubus- Kar- 
ten von sowie bei den PCI-Karten können 
neben dem Diskettenlaufwerk (als Image 
oder physikalisch) auch bis zu zwei Datei- 
en („Hardfiles"), als Festplatte eingebun- 
den werden. Auf- und Umsteigern ist es 
möglich, vorhandene Hardfiles von den 
Software-Emulatoren SoftPC, SoftWin- 
dows und Virtual PC oder von den Hard- 
ware-Vorgängern Mac286 und Orange386 
zumindest als zweite Festplatte D: zu ver- 
wenden. Darüber hinaus sind bis zu vier 
Shared Volumes (Macintosh Ordner oder 
andere Geräte wie ganze Festplatten oder 
optische Laufwerke) möglich. Ebenso ist 
beispielsweise ein ZIP-Drive als ATAPI- 
oder SCSI-Device einzubinden. Auch 
schaffte es Orange Micro, 32 Bit-Treiber für 
Festplatte, CD-ROM und Diskettenlaufwerk 
für die Windows 9X-Familie bereitzustel- 
len. Zumindest ab der 200er-Serie kann 
auch die Netzwerkschnittstelle des Mac ge- 
nutzt werden. Der Mac selbst sollte bis ein- 
schließlich der 500er Serie über mindes- 
tens 2 MByte RAM, für die Modelle der 
600er Serie besser 16 MByte RAM verbaut 
haben. 


Ein DOS-Mac 
direkt vom Hersteller 


Und was machte der Mac-Hersteller 
selbst? Commodore war auch Hersteller 
von PC-Emulatoren für den Amiga und hat 
quasi den Startschuss selbst gegeben. Ap- 
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ple hat zumindest AST als auch Orange 
weitreichend über die Interna der Macin- 
tosh Computer informiert, sodass eine gu- 
te Integration gelang. 

Die Konfiguration der Apple-eigenen PC- 
Emulationskarten erfolgt über die PC-Set- 
up-Software. Die seriellen Schnittstellen 
werden emuliert und auf den Modem- oder 
Printer-Port des Macs umgeleitet. Als Fest- 
platte für die PC-Welt dient auch hier ein 
sogenanntes Hardfile, es sind bis zu zwei 
als Laufwerke C: und D: möglich. Diese 
können auch von den Software-Emulato- 
ren SoftPC und SoftWindows stammen. 
Darüber hinaus ist noch ein Austauschord- 
ner mit dem Mac möglich, der dann beiden 
Systemen zur Verfügung steht. Auch ein im 
Mac vorhandenes CD-ROM-Laufwerk wur- 
de eingebunden. Der Zugriff auf ein Netz- 
werk klappt ebenfalls, allerdings nicht 
gleichzeitig — nur ein System, also der Mac 
oder der PC, vermag eine Netzwerkverbin- 
dung herzustellen. 

Im Oktober 1993 war es dann endlich so 
weit — Apple brachte mit dem Quadra 610 
seinen ersten Computer auf den Markt, der 
vom Werk aus PC-kompatibel ausgestat- 
tet war. Realisiert wurde das mit Hilfe der 
Houdini | genannten Erweiterungskarte für 
den PDS-Erweiterungsslot des Rechners 
mit 68040 CPU. Auf der Houdini | ist ein 
gesockelter Intel 486SX-Prozessor mit 
25/33 MHZ verbaut, zusammen mit einem 
PC-Chipsatz und einer VGA-Karte von 
Chips and Technologies mit 512 KByte 
Speicher. Der notwendige Arbeitsspeicher 
wird entweder vom Mac selbst zur Verfü- 
gung gestellt oder besser durch einen zu- 
sätzlich verbauten PS/2-Riegel mit bis zu 
32 MByte. Eine SoundBlaster-Karte lässt 
sich über einen kleinen Steckplatz einbau- 
en. Als Betriebssystem war DOS 6.22/ 
Win3.1 vorgesehen, aber auch Windows 
95 läuft mit der Karte. Das Video-Signal 
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des Mac wird über ein spezielles Kabel 
durch die PC-Karte durchgeschleift. So 
klappt ein Umschaltung zwischen Mac und 
PC. Wichtig war Apple auch die Anschluss- 
möglichkeit für einen PC-Joystick mit Hilfe 
dieses Kabels — das zeigt durchaus den 
propagierten Verwendungszweck. 

Die leicht modifizierte Houdini II Karte 
wurde mit einem anderen L-Adapter (an- 
gepasst für den PowerPC-601-PDS-Slot 
im Power Mac 6100) ab März 1994 mit ei- 
ner DX2-66 CPU verkauft. Sie kann auch, 
wenngleich nicht offiziell von Apple unter- 
stützt, im Power Mac 8100 und Quadra 
oder Centris 610 eingebaut werden. Im Ju- 
li folgte dann mit dem Performa 630 bzw. 
LC 630 eine LC-PDS-Slot-Variante, die 
ebenfalls einen 486DX2-66 mitbrachte. 

Mit dem Umstieg auf die PCI-Architek- 
tur, der ab dem Power Mac 7200 vollzogen 
wurde, wechselte Apple für seine PC-Kar- 
ten ebenfalls auf diesen Erweiterungs- 
steckplatz. Im April 1996 kam die 7“-Karte 
mit einem 100 MHz Cyrix 5x86-Prozessor, 
128 KByte L2-Cache und SIS-Chipsatz, so- 
wie eine 12“-Karte mit Intel Pentium 100 
CPU, 256 KByte L2-Cache und OPTI Vi- 
per-Chipsatz auf den Markt. Die kleinere 
Variante wurde mit einem 8-MByte-DIMM 
ausgeliefert, auf der größeren sind 8 MByte 
onboard verlötet. Beide Karten haben ei- 
nen ATI Mach64- Grafikchip mit 1 MByte 
(7*-Karte) oder bis zu 2 MByte (12“-Karte) 
VRAM sowie einen 16-Bit SoundBlaster Vi- 
bra 16S Soundchip. Apple behielt die Lö- 
sung mit einem Durchschleifkabel bei. 
Allerdings wurde der Joystick-Port des Ka- 
bels entfernt, da die Karten selbst einen 
solchen Anschluss vorsehen. 

Die PCI-PC-Karten waren für den Betrieb 
mit MS-DOS 6.22 und Windows 3.1 oder 
Windows 95 vorgesehen. Letztlich läuft auf 
ihnen aber auch Windows 98 problemlos, 
wenngleich es für Windows 9X-Systeme 
keine 32 Bit-Treiber für Festplatte, CD- 
ROM und Disklaufwerk gibt. Windows NT 
und auch OS/2 wurde zu keiner Zeit von 
den Apple-PC-Karten unterstützt. Auch 
können die PC-Emulatoren bis auf eine 
Ausnahme keine PCI-Erweiterungskarten 
ansprechen. Von Apple selbst gab es eine 
Karte mit einer seriellen und einer paralle- 
le Schnittstelle, die aber mit einem zusätz- 
lichen Kabel an den PC-Karten ange- 
schlossen werden musste. 

Für den Power Mac 
4400 (bzw. 7220) und 
Power Mac 7300 brach- 
te Apple dann ein Jahr 
später zwei überarbeite- 
te Versionen der 12*- 
Karte heraus. So ist als 
Grafikchip ein ATI 
Mach64VT mit 2 MByte 
Speicher sowie 16 
MByte Onboard-RAM 
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verbaut. Für den 4400er kommt ein Cyrix 
PR166 Prozessor mit 133 MHz zum Ein- 
satz. Diese Karte ist speziell nur für dieses 
Modell designed, da laut Apple das Netz- 
teil der anderen Macs keine ausreichenden 
Reserven bieten. Die maximale Ausbau- 
stufe, quasi die Krönung der herstellerei- 
genen PC-Karten ist die Variante für den 
7300er mit 166 MHZ Intel Pentium CPU. 
Die 166er Pentium-Karte ist das finale 
Meisterstück, denn Apple ließ mit dieser 
Erweiterung die Hardware-PC-Kompatibi- 
lität auslaufen. Zumindest die PCI-PC-Kar- 
ten wurden auch als sogenanntes „PC 
compatible upgrade kit“ verkauft. 


Aufgewärmtes 
von Reply und Radius 


Der Hersteller Reply lizenzierte nach dem 
Erscheinen der Houdini Il-Karten die Tech- 
nologie von Apple, die den PC-Karten zu- 
grunde lag. Dies zeigt sich unter anderem 
auch daran, dass zum Durchschleifen des 
MAC- Videosignals die gleichen Kabel wie 
bei den entsprechenden Apple-Karten ver- 
wendet werden. Die Einstellungen, die die 
Setup-Software zulässt, sind ähnlich zu den 
Apple-Karten. Allerdings ist es beiden Wel- 
ten (dem Mac-Host und dem PC-Gast) 
möglich, durch das extra zu erwerbende 
NetWork Pack gleichzeitig auf die Netz- 
werkschnittstelle zuzugreifen. Bis auf den 
Houdini II Klon können alle Karten auch ei- 
ne PClI-Schnittstellenkarte nutzen, die 
ebenfalls mit den Emulatoren per Kabel 
verbunden werden muss. Im Gegensatz zu 
den originalen Apple-Karten können die LC- 
PDS und PCI-Karten neben MS-DOS 6.22 
und Windows 3.1 und Windows 95/98 
(ebenfalls ohne 32 Bit-Treiber für Festplat- 
te, CD-ROM und Diskettenlaufwerk) auch 
Windows NT als Betriebssystem nutzen. 

Im Dezember 1995 brachte Reply eine 
sog. „DOS on Mac*-Karte für den PDS-Slot 
des Power Mac 7100 und 8100 heraus. 
Diese Karten bieten einen Sockel3 für 
486DX2 und DX4-Prozessoren sowie den 
Cyrix 5x86 in Verbindung mit einem Opti- 
Chipsatz, wobei kein L2-Cache vorgese- 
hen war. Es können bis zu 64 MByte Ar- 
beitsspeicher in Form eines PS/2-SIMMs 
verbaut werden. Reply verwendet den S3 
Trio32 mit 1 MByte RAM als Grafikchip. 
SoundBlaster-kompatiblen Sound gibt es 
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nur mit einem Zusatzmodul, das direkt auf 
der PC-Karte Platz findet. Beide Karten 
bauen letztlich auf dem gleichen Grundde- 
sign auf, wobei sie in ihrer jeweiligen Form 
auf die Vorgaben des entsprechenden 
Macs zugeschnitten sind. Zusätzlich war 
auch die Houdini Il-Karte als reiner Klon im 
Sortiment, wobei zusätzlich eine kleine Zwi- 
schenplatine zu erwerben war, die den An- 
schluss für das Kabel beim Mac 7100/8100 
nach hinten bis an ein Slotblech verlängert. 

1996 brachte Reply eigene Interpretati- 
onen der PCI-PC-Karten von Apple auf den 
Markt. Die 7*-Karte kann bis zu 128 MByte 
Arbeitsspeicher aufnehmen und die CPU 
ist gegen eine 133 MHz AMD-5x86-CPU 
getauscht. Größere Veränderungen gab es 
bei der 12“-Variante der letzten Apple- Ent- 
wicklungsstufe. Neben der Möglichkeit, bis 
zu 128 MByte Arbeitsspeicher zu verwen- 
den (auf Kosten des Onboard-Speichers), 
wurde die CPU gesockelt und so gibt es 
Versionen mit Pentium 133, Pentium 166- 
MMX, 200 MMX und auch 233 MMX. Dar- 
über hinaus kann auch der L2-Cache mit 
einem entsprechenden SIMM-Modul von 
256 KByte auf 512 KByte und der Vide- 
ospeicher auf bis zu 4 MByte aufgerüstet 
werden. 

Der Staffelstab der PC-kompatiblen Kar- 
ten wurde im April 1997 durch den Verkauf 
der DOS on Mac Technologie an Radius 
weitergegeben. Diese verkauften die obi- 
gen Karten weiter und es gab zusätzlich 
noch DOS-on-Mac Karten für den LC-PDS 
Steckplatz wie der Macintosh 6200er Serie. 
Diese Karte ist von der Grundkonzeption 
offensichtlich denen für den PCI-Steckplatz 
ähnlich und nutzt ebenfalls einen AMD 5x86 
Prozessor mit 133 MHz. Weitere Informa- 
tionen dazu waren leider nicht auffindbar. 

Letztlich zog sich Radius schleichend ab 
1997 vom Apple-Hardware- Markt zurück. 
Somit gab es auch von dieser Seite keine 
Weiterentwicklungen der Apple PC Com- 
patible Cards mehr. 


Aufgegessen - 
DOSen Macs sind aus 


Und plötzlich war es vorbei — nachdem 
von den Apple-Karten ab 1997 keine Wei- 
terentwicklungen mehr herausgebracht 
wurden, kam, wie bereits erwähnt, Ende 
1998 das Finale für die OrangePC-Linie. 


Warum wurden bei- 
de vielversprechen- 
den Produktlinien 
nicht mehr gepflegt? 
Zum einen war da si- 
cher der Preis, denn 
schließlich kostete 
eine PC-kompatible 
Karte für den Mac, 
vor allem die leis- 
tungsfähigen wie die 
OrangePC 660 fast 
so viel wie ein adäquater PC. Der bot dann 
aber noch die normalen Erweiterungsmög- 
lichkeiten mit AGP-Grafik und anderem. 
Viel entscheidender war aber, dass es für 
diesen Aufwand eigentlich keine Rechtfer- 
tigung mehr gab. Die PC-Karten wurden 
zum einen zum DOS und Windows- kom- 
patiblen Arbeiten benutzt. Inzwischen lie- 
ßen sich die Dateien von Windows-Office 
und Mac-Office problemlos austauschen 
und es gab von den meisten Business-Pro- 
grammen Lösungen für beide Welten. Zum 
anderen fiel auch der zweite, vor allem für 
die letzten Karten besonders wichtige 
Grund weg: Die Karten wurden oft als die 
Möglichkeit angepriesen, endlich am Mac 
richtig spielen zu können. Das zeigt sich im 
Anschluss für einen Joystick, den sogar 
schon die Houdini | Karte bereitstellte. Mit 
den leistungsfähigen PowerPC Prozesso- 
ren ab der G3- Serie und vor allem dem Er- 
scheinen von Grafikkarten mit flotten ATI-, 
3Dfx und nVidia-Chips für den PCI-Bus im 
Mac wurde auch dieser selbst zu einer 
Spieleplattform. Die wichtigsten Titel wur- 
den für MacOS veröffentlicht. Und wer, aus 
welchen Gründen auch immer, noch ein 
DOS- oder Windows-System am Mac lau- 
fen lassen wollte, für den hatten diese Pow- 
erPC-Prozessoren genug Leistung, um das 
ausreichend flüssig mit einer Software- 
Emulation wie Virtual PC zu bewerkstelli- 
gen. 

Den letzten Rechtfertigungsgrund verlor 
diese „Brückentechnologie“ letztlich einige 
Jahre später. 2006 wechselte Apple von 
der PowerPC-Architektur hin zur Intel-Welt. 
Damit lief Microsoft Windows sogar nativ 
auf der Macintosh Hardware und Boot 
Camp ermöglichte den Dual Boot zwischen 
MacOS X und der Windowswelt. 


Software 


SuSE Linux als Server für viele Plattformen 


SuperNOS im 
Eigenbau 


Einst hatte Novell Inc. große Pläne: Netware 4.1 sollte 
mit Unixware Version 2 zu einem Betriebssystem ver- 
schmelzen, dem SuperNOS. Wäre es nach CEO Ray 
Noorda gegangen, hätte eine Codebasis sowohl Unix- 
als auch PC-Netze versorgt. 1995 wurden diese Pläne 
still zu Grabe getragen. Doch nichts hindert den beherz- 
ten Retrocomputing Fan, sich ein entsprechendes Be- 
triebssystem selbst zu bauen. 


1993 übernahm Novell die Unix System 
Laboratories inklusive des Gemeinschafts- 
produkts Univel, einem Unixderivat von 
AT&T. Unter dem Namen Unixware vermar- 
ket, war dieses Produkt parallel zur sehr 
erfolgreichen Novell Netware aufgestellt. 
1994 kündigte Robert Frankenberg, Vor- 
standsvorsitzender von Novell, diese bei- 
den Produkte würden verschmelzen. Das 
neue, intern als SuperNOS bezeichnete 
Produkt, sollte einen modularen, verteilten 
Mikrokernel besitzen und sowohl UNIX- als 
auch PC Netze mit Netware-Clients bedie- 
nen können. Doch aus der für 1997 geplan- 
ten Veröffentlichung wurde nichts -- der 
Markt hatte sich nicht zuletzt durch Micro- 
soft Windows NT zu ungunsten von Novell 
verschoben. 1995 wurde Unixware an die 
Santa Cruz Operation (SCO) verkauft, wel- 
che im Anschluss vor allem durch unbeleg- 
te Behauptungen bezüglich Copyright- 
Verletzungen durch Linux von sich Reden 
machte und nicht durch ein SuperNOS. 

Doch ein Betriebssystem, das sowohl 
Unix Rechner als auch MSDOS Maschinen 
im Netz mit Datei- und Druckdiensten ver- 
sorgt, muss kein Traum bleiben. Mehr noch 
-- mit freier Software und der richtigen Kon- 
figuration wird ein Server zur Realität, der 
neben Clients unter Unix oder MSDOS 
auch Windows- und Macintosh Clients ver- 
sorgt. Dieser Artikel beschreibt, wie sich 
ein derartiger Netzwerkserver leicht selbst 
aufbauen lässt. Ziel ist es, einen Server 
aufzusetzen, der Verzeichnis- und Drucker- 
freigaben für MSDOS- und Windowsclients 
ebenso bereitstellt wie für Unix-Systeme 
und klassische Apple Macintosh Rechner. 
Der Server soll also Netware Laufwerke, 


Windows Shares, Macintosh Laufwerke 
und NFS Verzeichnisse bereitstellen. 

Das ist in vielerlei Hinsicht eine große 
Aufgabe. Jede dieser Serverfunktionen hat 
ihre eigene Architektur und funktioniert 
nach eigenen Regeln. Die Hintergründe 
und Technologien im Detail zu beschrei- 
ben, würde ganze Bücher füllen. Dieser Ar- 
tikel streift diese daher nur am Rande und 
nur soweit, wie es für das Verständnis der 
beschriebenen Serveremulationen nötig 
ist. Wer sich in die Hintergründe einarbei- 
ten möchte, kommt um ein Studium der 
zahlreichen Quellen im Internet nicht her- 
um. Dies gilt auch für den Umgang mit Li- 
nux als Basis für unseren SuperNOS 
Server. 


SuSE Linux 9 als Basis 


Als Ausgangspunkt für das eigene Su- 
perNOS ist eine ältere Linux-Distribution 
vonnöten. Neben der Serversoftware selbst 
auf der Anwendungsebene braucht es auch 
die passenden Netzwerkprotokolle. Novell 
Netware benötigt IPX, Windows will NetBl- 
OS over TCP/IP beziehungsweise SMB 
(Server Message Block), ein Macintosh 
möchte AppleTalk oder genauer EtherTalk 
sehen und Unix das NFS Protokoll. Aktu- 
ellen Linux Kernel fehlt aber der IPX- und 
AppleTalk Protokollstack. Also muss also 
passend zur Aufgabe ein angestaubter Kar- 
ton aus dem Regal gezogen werden. Die 
beste Wahl ist SUSE Linux in Version 9.1. 
Vom Bedienkomfort schon recht weit ent- 
wickelt, bringt diese Version alle erforder- 
lichen Module der Netzprotokolle im Kernel 
mit und auch die Serversoftware selbst ist 
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im Grundumfang enthalten. SuSE Linux 9.1 
lässt sich kostenfrei herunterladen und in- 
stallieren, die erforderlichen Internet Links 
finden sich am Ende des Artikels. 

Für diesen Artikel wurde ein Pentium Ill 
Rechner mit 512 MByte Arbeitsspeicher 
und einer 4 GB PATA Festplatte genutzt. 
Ein solcher Rechner sollte sich leicht auf- 
treiben lassen. Zu neu darf die Maschine 
aber nicht sein, denn SuSE Linux 9.1 un- 
terstützt neue Hardware natürlich nicht so 
gut wie aktuelle Linux Distributionen. Prin- 
zipiell ist auch die Installation als virtuelle 
Maschine denkbar. Jedoch haben die vor- 
angehenden Experimente gezeigt, dass 
viele Virtualisierungsplattformen die Netz- 
protokolle jenseits von TCP/IP oft nicht kor- 
rekt durch reichen. Hier gilt es also, echte 
Hardware einzusetzen, um sich Probleme 
schon am Anfang zu ersparen. 

Die Installation passiert menügeführt und 
im Grafikmodus, sie ist für einen geübten 
Retrocomputer-Fan keine Herausforde- 
rung. Die übrige Konfiguration und erfolgt 
dann mit dem Tool YaST (yet another set- 
up tool) der SuSE Distribution. Dies sollte 
auch konsequent genutzt werden, wo im- 
mer es möglich ist. Das Tool ist sowohl mit 
einer grafischen Oberfläche verfügbar als 
auch in einem Konsolenfenster im Textmo- 
dus. Das ist praktisch, um einen einmal auf- 
gesetzten Server über eine ssh- 
Verbindung zu administrieren. YaST ist 
auch dafür zuständig, nachträglich fehlen- 
de Softwarepakete zu installieren und Soft- 
ware-Updates einzuspielen. 

Für die übrige Konfiguration brauchen 
wir nur noch ein Verzeichnis anzulegen, 
das später die im Netz bereitzustellenden 
Dateien aufnimmt. Am besten eignet sich 
hierfür ein Verzeichnis unterhalb von /var, 
in den folgenden Beispielen ist /var/share 
gewählt. Alle Konfigurationsarbeiten in die- 
sem Artikel werden mit den Rechten des 
Systemverwalters ausgeführt, also vom 
Benutzer "root". Die Beispielkonfiguratio- 
nen sind übrigens auf der CDROM zum 
Heft vorhanden. Wer also die Installation 
nachvollziehen möchte, kann diese einfach 
übernehmen. 


NFS Server aufsetzen 


UNIX Rechner im Netz nehmen am ein- 
fachsten den Kontakt über NFS mit unse- 
rem SuperNOS auf. NFS ist ein Netz- 
protokoll für den Export von Verzeichnis- 
bäumen auf andere Rechner. Es wurde ur- 
sprünglich von Sun Microsystems Ende der 
1980er Jahre entwickelt. Heute ist es als 
Internet Standard in mehreren RFC's stan- 
dardisiert. Um als NFS Server funktionie- 
ren zu können, sind mittels YaST die Pakete 
„hfs-server" und „nfs-utils" zu installieren. 
Erforderliche Abhängigkeiten zu anderen 
Paketen löst YaST automatisch auf und in- 
stalliert diese nach Rückfrage gleich mit. 
Seine Konfiguration erledigt YaST mit der 
Funktion „Netzwerkdienste / NFS-Server". 
Als zu exportierendes Verzeichnis wählen 
wir var/share mit den Optionen rw,root_s- 
quash,sync. Dadurch wird das Verzeichnis 
beschreibbar exportiert (rw), Clientzugriffe 
durch den Systemverwalter root werden 
auf den User nobody umgebogen (root_S- 
quash) und der NFS Server meldet einen 
Schreibvorgang erst dann als abgeschlos- 
sen zurück, wenn die Daten wirklich auf die 
Platte geschrieben wurden (sync). Die Zu- 
griffsberechtigung ließe sich auf bestimm- 
te Rechner oder Netze eingrenzen, indem 
diese entsprechend aufgelistet werden. Für 
unseren Server reicht hier ein Wildcard- 
Zeichen (*), dadurch erhalten alle Clients 
den Zugriff. Die Konfiguration wird in der 
Datei /etc/exports abgelegt und dort vom 
NFS Serverdaemon gelesen. 


Samba für Windows Clients 


Windows Rechner kennen ab der Versi- 
on Windows für Workgroups 3.11 (WfW) 
eigene Netzfunktionen (Peer-to-Peer Net- 
ze). Spätere Versionen haben zusätzliche 
Funktionen erhalten und Microsoft zum füh- 
renden Anbieter für Serverbetriebssyste- 
me im LAN gemacht. Um unser SuperNOS 
auch in diesen Netzen heimisch werden zu 
lassen, braucht es den Server Samba. 
Samba ist eine Entwicklung, die ursprüng- 


( ) Samba-Server deaktivieren 
(x) Samba-Server aktivieren 


Freigabe- 


lich von dem Australier Andrew Tridgell im 
Jahr 1992 begonnen wurde. Sie sollte den 
Datenaustausch zwischen SunOS und 
DOS auch ohne NFS ermöglichen. Samba 
implementiert dazu die Netzfunktionen von 
Windows Netzen (Server Message Block, 
SMB) auf UNIX und ermöglicht die Kom- 
munikation mit SMB über TCP/IP. Mit der 
Portierung auf Linux begann der Sieges- 
zug der Software. Sie wird bis heute wei- 
terentwickelt und ist Bestandteil so ziemlich 
jedes Consumer NAS. War die ursprüngli- 
che Samba Version auf Peer-to-Peer Ebe- 
ne angesiedelt, so kann Samba heute 
selbst die Rolle des Domänencontrollers 
übernehmen und die Active Directory Do- 
main Services auf einem Linuxsystem be- 
reitstellen. Dementsprechend komplex ist 
auch die Konfiguration von Samba gewor- 
den. An dieser Stelle begnügen wir uns 
aber mit einer einfachen Grundkonfigura- 
tion. Sie ist auch auf der Heft-CDROM zu 
finden. 

YaST konfiguriert Samba über das Me- 
nü unter „Netzwerkdienste / Samba-Ser- 
ver“. Aufgrund der vielen Einstellungsmög- 
lichkeiten empfiehlt es sich aber, die 
Konfiguration direkt in der Datei /etc/sam- 
ba/smb.conf vorzunehmen.Sie richtet den 
Server mit dem Namen SMBSUPERNOS 
ein und definiert eine Arbeitsgruppe SU- 
PERNOSGROURP. Für jeden Benutzer, der 
Zugriff auf diesen Server habe soll, braucht 
es zweierlei: Es ist ein Eintrag auf in die Li- 
nux Benutzerdatenbank nötig und Samba 
braucht einen Eintrag in der eigenen Be- 
nutzerliste. Der Linux Benutzer ist mit YaST 
unter Sicherheit und „Benutzer / Benutzer" 
bearbeiten und anlegen schnell erstellt. Der 
Name des Benutzers in diesem Beispiel ist 
einfach „user". Anschließend wird dieser 
Benutzer auch für Samba eingerichtet, und 
zwar mit dem Befehl smbpasswd von der 
Kommandozeile aus: 
smbpasswd -a user 

Das Passwort sollte mit dem des Linux 
Benutzers identisch sein. 


(x) Freigabe von Dateien und Druckern 


( ) Backup Domain Controller 


( ) Primary Domain Controller 


Domain oder Arbeitsgruppe: 


SUPERNOSGROU 


Server-Beschreibung: 


Supernos Samba Vers vi 


Name des Server-NetBIOoS: 


SMDSUPERNC STE 


[Authentifikationsdetails] 


[Durchsuchen] 


Samba Konfiguration 


[global] 

| Netzwerk 

interfaces = 192.168.0.100 

bind interfaces only = Yes 

A Servername 

netbios name = SMBSUPERNOS 

workgroup = SUPERNOSGROUP 

server string = SuperNOS Samba 
Vers %v 

socket options = TCP_NODELAY 
SO_SNDBUF=12288 SO_RCVBUF=12288 

pressen Zugriffssteuerung 

security = user 

passdb backend = tdbsam 

lanman auth = Yes 

client lanman auth = Yes 

client plaintext auth = Yes 

ntlm auth = yes 

nee WINS 

; dieser Samba Server ist WINS 
Server 

wins support = yes 

g: assn Browsing 

domain master = yes 

local master = yes 

preferred master = yes 

os level = 200 

guest account = nobody 


iR 25 Drucken 
load printers = yes 
E} Werrirseie Logging 

log file = 


/var/log/samba/log.%m 
max log size = 50 
log level = 3 
[share] 
writeable = yes 
path = /var/share 
force group = users 
comment = Offenes Verzeichnis 
auf SuperNOS mit SMB 
valid users = @users 
create mode = 0750 
public = yes 
[user] 
comment = User's Netzlaufwerk 
valid users = user 
path = /home/user 
wide links = no 


Netatalk für Macintosh Clients 


Apple Macintosh Systeme haben von An- 
fang an eigene Netzfunktionen mitge- 
bracht, nämlich AppleTalk. Urspünglich 
funktionierte die Netzkommunikation über 
serielle RS422 Busverkabelung als Local- 
Talk. Die Netzfunktionen sind aber in meh- 
reren Protokollschichten realisiert und 
lassen sich als Ethertalk auch über Ether- 
net betreiben. Mit Netatalk stehen die Da- 
tei- und Druckserverfunktionen auch unter 
Linux zur Verfügung. Damit können wir von 
einem Macintosh aus auf Daten auf einem 
Linux-Rechner zugreifen oder auf einem 
angeschlossenen Drucker drucken. Ne- 
tatalk ist eine Reihe von Unix-Programmen, 
die auf dem kernelbasierten DDP (Data- 
gram Delivery Protocol) laufen und die Ap- 
pleTalk-Protokollfamilie (ADSP, ATP, ASP, 


Software 


Netatalk Konfiguration 


Die Konfiguration des MAR.S NWE erfolgt 
in einer zentralen Konfigurationsdatei, die 
als /ete/nwserv.conf abgelegt ist. Sie enthält 
eine sehr ausführliche Beschreibung der 
möglichen Einstellungen in Form von Kom- 
mentaren. Die hier gezeigte Beispielkonfi- 
guration zeigt nur die Einträge, die bei 
einem typischen Einsatzfall verändert wer- 
den müssen. Die Einträge erzeugen beim 
ersten Start die emulierte Bindery. Spätere 
Änderungen erfordern daher den Aufruf von 
nwserv -h , um wirksam zu werden. 


Jede Einstellung wird innerhalb der Datei 
durch eine Sektionsnummer gekennzeich- 
net, es können mehrere Zeilen mit der 
gleichen Sektionsnummer vorkommen. 
Zeilen, die mit einem Hash-Mark (#) be- 
ginnen, sind Kommentare und werden als 
solche von MAR.S NWE ignoriert. Der er- 
ste Eintrag gibt eine Zuordnung von Linux- 
Verzeichnissen zu NetWare-Volumes an: 


1 SWS 
/usr/local/nwe/SYS/ 
See 
1 SHARE /var/share 

kt 777 666 
Es muss immer ein SYS: Volume existier- 
en, es können weitere Definitionen folgen. 
Zu beachten ist, dass der jeweilige Linux- 
pfad (hier /var/local/nwe/SYS) vor dem 
Start des Servertasks auch tatsächlich be- 
steht, sonst wird der Eintrag dauerhaft ig- 
noriert. Im Falle des SYS: Volumes müssen 
auch Unterverzeichnisse mail, public, login 
und system existieren. Das Flag "k" legt 
fest, dass alle Datei- und Verzeichnisna- 
men in Kleinschrift erwartet werden, was 
bei der Bezeichnung von Dateien unter 
Linux meist die Regel ist. Das "t" Flag er- 
möglicht die Verwendung von Trustees für 
die Vergabe von Rechten an den Dateien, 
also einer differenzierten Art der 
Rechtevergabe und einer Spezialität von 
Novell NetWare. Durch den Eintrag 


1 CDROM 
irm 
würde ein Volume CDROM! definiert, das 
auf dem Mountpoint für CDROMSs unter 
Linux verweist. Dabei sind die Flags be- 
sonders wichtig: "i" bewirkt ein Ignorieren 
von Groß- und Kleinschrift, "r" weist das 
Volume als "read only" aus und "m" ermög- 
licht ein erneutes Mounten des Daten- 
trägers, während der Emulator noch läuft, 
also ein Austauschen der Silberlinge im 
laufenden Betrieb. Möglich ist auch ein 
Eintrag in der Form 


1 HOME = 
kio 


/mnt/cdrom 


RTMP, NBP, ZIP, AEP und PAP) implemen- 
tieren. DDP wird vom Kernelmodul „apple- 
talk" bereitgestellt. Das ist aber auch 
gleichzeitig der Pferdefuß: Neuere Linux 
Distributionen enthalten dieses Modul nicht 
mehr, weil es für Mac OS X nicht mehr be- 
nötigt wird. Das ist einer der Gründe, wie- 
so in diesem Artikel mit SUSE Linux 9.1 
gearbeitet wird, denn hier ist das Modul von 


denn dieser macht für jeden Benutzer 
getrennt das Heimatverzeichnis unter Linux 
mit dem Volumenamen HOME: erreichbar. 


Um den NetWare-Serverdienst im Netz- 
werk eindeutig zu identifizieren, wird nor- 
malerweise der Hostname des 
Linux-Rechners verwendet. Bei Clients, die 
auch TCP/IP verwenden und einem Linux- 
Rechner (hier SUPERNOS), der parallel zu 
MAR.S NWE auch Samba verwendet, kann 
dies zu Verwirrungen führen. In der Netz- 
werkumgebung von Windows 95/98 wird 
der Rechner doppelt auftauchen, einmal als 
SMB- und einmal als NetWare-Server. 
Besser ist es, dem Net\WWare-Server einen 
eigenen Namen zuzuweisen: 


2 NWSUPERNOS 

Die beiden nächsten Einträge legen die 
Konfiguration des IPX Protokolls fest. Es ist 
zunächst notwendig, für den Server ein in- 
ternes Netz (Sektion 3) festzulegen. Dieses 
virtuelle Netz dient dem Routing von Daten 
vom realen Netz zum Serverprozess und 
muss im Netzwerk eindeutig sein. Eine 
Konvention bei der Einrichtung von Net- 
Ware-Servern schreibt hier die Verwendung 
der MAC Adresse der Ethernetkarte für das 
"PX internal net" vor. Man kann hier dem 
Server die Wahl auch selbst überlassen, 
der dann allerdings die IP Adresse des 
Linux-Rechners zur Erzeugung einer 
eindeutigen Adresse bemüht. Dies setzt 
eine funktionierende TCP/IP Konfiguration 
voraus. In Sektion 4 findet eine Konfigura- 
tion der Netzwerk-Interfaces statt, als erster 
Parameter steht die Netzwerknummer, die 
ebenfalls eindeutig für den Server sein 
muss. Dann folgt die Angabe des Netz- 
werk-Devices und des gewünschten Ether- 
net-Frames. Hier ist "ethernet ii" die 
richtige Wahl für Netzwerke, in denen auch 
TCP/IP Datenverkehr abläuft. Wichtig ist 
hierbei, dass auch die Clients diesen Rah- 
mentyp verwenden, da sonst niemals eine 
Verbindung zum Server zustande kommt. 
Sektion 5 legt fest, wie mit den erzeugten 
IPX Einstellungen nach dem Stop des 
Serverprozesses umzugehen ist; der Ein- 
trag 0x1 verhindert ein Rücksetzen der 
Parameter nach dem Server-Shutdown. 


3 auto al 

4 0x10 eth0 ether- 
net_ii 1 

5 0x04 


Gibt man in der Sektion 4 mehrere Inter- 
faces an, so routet der MAR.S NWE auto- 
matisch zwischen diesen. 

Die Sektionen 6 (NetWare-Version), 7 und 
8 (Passwort-Handling) können getrost auf 
den Voreinstellungen belassen werden. In- 


Anfang an vorhanden. Netatalk besteht 
normalerweise aus drei Servern: 

atalkd (“AppleTalk Network Mana- 

ger”) für das Netzprotokoll selbst 
afpd (“AppleTalk Filing Protocol 
daemon”) für Verzeichnisfreigaben 
papd (“Printer Access Protocol dae- 
mon”) für Druckerfreigaben 
Wichtig ist es, die Einschränkungen von 


teressanter ist da schon der folgende Ein- 
trag: Er gibt die Rechtemaske für das 
Anlegen von Verzeichnissen und Dateien 
auf Linux-Ebene an. In der Regel lautet der 
Eintrag hier 

9520751 0640 

wodurch neue Verzeichnisse mit den 
Rechten drwxr-x--x und Dateien mit rw-r--- 
-- angelegt werden. Dies beschränkt den 
Vollzugriff also auf den Eigentümer der 
Dateien. 


Unter Novell NetWare besitzt jeder Client 
bereits eine Zugriffsmöglichkeit auf den 
Server, ohne dass eine Anmeldung an 
diesem erforderlich ist. Dieses Server-At- 
tachment dient der Bereitstellung einer Lo- 
gin-Möglichkeit und birgt für die Linux-Seite 
ein Sicherheitsrisiko: Es besteht ein offen- 
er Systemzugang ohne Passwort-Absicher- 
ung. Durch die Sektionen 10 und 11 ist 
daher die Festlegung einer Benutzer- und 
Gruppenidentität möglich, Zugriffe über 
eine "attach" Verbindung sind dann diesem 
Benutzer zugeordnet. Hier sollte der Be- 
nutzer "nobody" aus der Gruppe "nogroup" 
eingetragen werden, dessen ID sich leicht 
durch ein grep nobody /ete/passwd unter 
Linux ermitteln läßt; ein Ergebnis könnte 
lauten: 


nobody:x:65534:65534::/tmp:/bin/false 


Das erste Auftreten des Wertes "-2" stellt 
die Benutzer-ID (UID) dar, das zweite die 
Gruppen-ID (GID). Die UID gehört in Sek- 
tion 10, die GID in Sektion 11: 


10 65534 

11 65534 

Zu beachten ist, daß "nobody" kein 
Schreibrecht auf das Verzeichnis besitzt, 
da sonst ein Attentat auf das System durch 
das Vollschreiben der /var Partition möglich 
wäre. Ist diese Partition erst einmal zu 
100% ausgelastet, bringt das alle Prozesse 
zum Stehen, die hier Daten ablegen. 


Die Sektionen 12 und 13 legen die Be- 
nutzer des NetWare-Emulators und die 
Zuordnung dieser zu bestehenden Linux- 
Benutzern fest. Dabei bestimmt der Eintrag 
12 den Namen und das Passwort des Sys- 
temadministrators, also zumeist SUPER- 
VISOR. In der folgenden Sektion können 
nun alle Benutzer explizit aufgeführt wer- 
den, diese werden nach dem ersten 
Starten des Emulators in die Bindery über- 
nommen. Danach sollte man aus Sicher- 
heitsgründen zumindest das 
Initial-Password des Supervisors wieder 
aus der Datei löschen, es bleibt in ver- 
schlüsselter Form in der Bindery enthalten. 


12 SUPERVISOR root 


gaben. 


supernos 

13 GUEST nobody 
"rt 

13 USER 

user SUPERNOS 

(Oil 


Alternativ dazu lassen sich auch alle schon 
auf dem Linux-Rechner vorhandenen Be- 
nutzer mit einem identischen Initialpasswort 
in die Bindery übernehmen. Dieses Ver- 
fahren erspart bei hoher Benutzeranzahl 
einige Arbeit und reduziert die Gefahr von 
falschen Einträgen : 


15 supernos 
Dadurch übernimmt der Emulator alle 
lokalen Benutzer in die Bindery und setzt 
ihr NetWare-Passwort auf "supernos". 


Die folgenden Sektionen können gefahrlos 
auf den Default-Einstellungen verbleiben, 
interessant wird es erst wieder in der Sek- 
tion 22. Hier findet nämlich die Einstellung 
der Druckdienste statt: 


lee = 
Der Eintrag leitet Druckdaten über einen 
Druckereintrag (Ip) in der /etc/printcap 
direkt an einen angeschlossenen Laser- 
drucker. Wichtig ist hier, dass die ent- 
sprechenden Druckbefehle auch wirklich 
funktionieren. Positive Druckergebnisse er- 
halten die NetWare-Clients nur, wenn auch 
Linux drucken kann. 


Von den folgenden Einträgen sind nur 
wenige für den Anfang interessant. Der 
Ordnung halber sollte man die Pfade in den 
Sektionen 40-47 für die Bindery- und Trus- 
teespeicherung auf ein entsprechendes 
Verzeichnis richten (z.B. /var/Inwserv) richt- 
en. Außerdem ist es ratsam, in Sektion 201 
den Eintrag "syslog" zu ergänzen, was 
eine Übergabe von Meldungen des Emu- 
lators an den Systemprotokollschreiber 
syslogd des Linux-Rechners bewirkt. Von 
dort lassen sich die Einträge zentral ver- 
walten, was das Leben des Systemadmin- 
istrators deutlich erleichtert. 


Nach der Erstellung und dem Test der Kon- 
figuration braucht man nicht mehr Hand an 
diese Datei zu legen. Die weitere Adminis- 
tration des Systems geschieht bequemer 
von einem Client-PC aus mit Tools wie "sy- 
scon" oder dem Netware Assistant. Viele 
Einstellungen wie das Anlegen von Ben- 
utzergruppen, der Einstellung von Login- 
Scripts oder von Zeitrestriktionen sind nur 
auf diesem Wege möglich. Die Speicher- 
ung erfolgt in dann wie es sich gehört in 
der Bindery des Emulators. 


Aljakz 


Netatalk zu kennen. Zunächst dürfen Pass- 
wörter für Benutzer nicht länger als 8 Zei- 
chen sein. Macintosh Clients können aus- 
serdem keine Dateien nutzen, deren 
Namen länger als 31 Zeichen sind oder den 
Doppelpunkt enthalten. MacOS nutzt den 
Doppelpunkt als Trennzeichen in Pfadan- 


Netatalk nutzt zur Benutzerauthentifizie- 
rung die Linux Benutzerdatenbank. Unser 
oben eingerichteter Benutzer "user" wird 
also auch hier genutzt. 

Die Konfiguration erfolgt über die Datei- 
en unterhalb des Verzeichnisses /etc/ne- 
tatalk. Hier liegen folgende Dateien: 


netatalk.conf 


bestimmt, welche Netatalk Daemons ge- 
startet werden sollen. 


atalkd.conf 


gibt an, über welche Schnittstellen Diens- 
te bereitgestellt werden. Wenn der Server 
gestartet wird, sucht er das Netzwerk nach 
vorhandenen Zonen und Servern ab und 
ändert die entsprechenden Zeilen, indem 
er die eingestellten AppleTalk-Netzwerk- 
adressen einträgt. 


afpd.conf 


enthält Definitionen dafür, wie der Ser- 
ver auf MacOS-Rechnern als Element im 
Dialogfeld „Auswahl" angezeigt wird. 


papd.conf 


definiert die Drucker für die MacOS Cli- 
ents. 


AppleVolumes.default 


definiert die zu exportierenden Verzeich- 
nisse. Die Zugriffsrechte definieren die üb- 
lichen Unix-Benutzer- und Gruppenrechte. 
Dies wird in der Datei AppleVolumes.de- 
fault konfiguriert. Neben der Datei Apple- 
Volumes.default können weitere Dateien 
existieren, z.B. AppleVolumes. guest, die 
von einigen Servern verwendet wird. 


AppleVolumes.system 


bestimmt, welche MacOS-üblichen Typ- 
und Erzeugerangaben bestimmten Datei- 
endungen zugeordnet werden. Meist ge- 
nügen die Standardwerte. Erscheint eine 
Datei auf dem MacOS Client mit einem all- 
gemeinen weißen Symbol, so gibt es für 
sie hier keinen Eintrag. Dann ist hier eine 
Ergänzung nötig. 

Für diese Dateien auf der CDROM zum 
Heft passende Beispiele zu finden. Sie de- 
finieren einen Server ASUPERNOS mit ei- 
ner Verzeichnisfreigabe „share" für 
/var/share. Die Dokumentation zu SuSE Li- 
nux liefert in Kap. 17 weitere Informationen. 


MAR.S NWE emuliert Novell 
Netware 


Novell Netware war lange der unange- 
fochtene Marktführer, wenn es um Netz- 
werke für IBM PCs ging. Ein durchdachtes 
System für Rechtevergaben auf der Ser- 
verseite und eine recht einfache Konfigu- 
ration der Clientseite machten Netware so 
beliebt. Auch die Nachbildung der Datei- 
und Druckdienste ist unter Linux möglich, 
und zwar mit dem Emulator MAR.S NWE 


von Martin Stover. 
Er wurde bis zur 
Version 0.99p111 
weiterentwickelt 

und ist in der Ver- 
sion auch Be- 


Netatalk Konfiguration 


AppleVolumes.default: 


- mswindows, codepage:maccode.iso8859-1 


:DEFAULT:limitsize:500000000 allow:@users 


standteil der 
Paketquellen von 
SuSE Linux 9.1. 
Neben der Funkti- 


rwlist:@users 
/var/share 


netatalk.conf: 


on eines RIP/SAP AFPD_MAX_CLIENTS=20 
ATALK_NAME=supernos 


Routers vermag 
MAR.S NWE so- 
wohl Datei- als 
auch Druckdiens- 
te anzubieten. 
Auch hier lassen 
sich beliebige Tei- 
le des Linux-Ver- 


ATALK_ZONE="!" 
AFPD_GUEST=nobody 
ATALKD_RUN=yes 
PAPD_RUN=yes 
AFPD_RUN=yes 
TIMELORD_RUN=no 
ATALK_BGROUND=yes 


. . atalkd.conf: 
zeichnisbaumes 
zu Volumes erklä-_ eth0 -phase 2 
ren und für Clients afpd.conf: 
freigeben. i n 
asupernos 
Voraussetzung 


für den Betrieb 

von MAR.S NWE 

ist die Unterstüt- 

zung des IPX Protokolls durch den Linux- 
Kernel. IPX ist im Standardumfang eines 
jeden Kernels der Version 2.0.x oder höher 
enthalten und bereits als Modul in der Su- 
SE Distribution als Modul vorhanden. Der 
Emulator implementiert den Wortschatz 
des 'netware core protocols' (NCP) und 
kommuniziert über IPX. Hierbei handelt es 
sich um Prozeduren, die der NetWare Ser- 
ver ausführt, um Anfragen von Clients über 
das Netz entgegen zu nehmen und zu 
beantworten. Sie erlauben es auch, Net- 
Ware-Server über das Netz zu administrie- 
ren. Novell stellt hierfür Programme (wie 
syscon oder nwadmin) auf dem Server be- 
reit. Diese funktionieren auch mit MAR.S 
NWE, wenngleich nicht in vollem Umfang. 
Informationen zur Verwaltung von Ressour- 
cen wie Benutzer- und Gruppendefinitio- 
nen, Drucker, Laufwerke, aber auch von 
Eigenschaften wie Zugriffsrechten und 
Kontoinformationen emuliert MAR.S NWE 
sogenannte Bindery, also eine an einen 
Server gebundene Datenbank. Jeder Be- 
nutzer von MAR.S NWE muss getreu der 
Netware 3- Vorgaben in der Bindery des 
Emulators eingetragen sein, was entweder 
durch die Übernahme aller Benutzer des 
Linux-Rechners oder durch einzelne Ein- 
träge in der zentralen Konfigurationsdatei 
geschehen kann. Beim ersten Start des nw- 
serv Programms wird anhand dieser Kon- 
figuration eine Bindery generiert und auf 
einem voreingestellten Pfad abgelegt. 

Zur weiteren Administration des Systems 
lohnt es sich, den Inhalt des SYS:PUBLIC 
Verzeichnisses eines NetWare 3.x Servers 
auf das Pendant von MAR.S NWE kopie- 
ren. Hierzu reicht die Version einer 2-User 


"share" 


-net 0-65534 


aipaddeziı Sie 
uams_dhx.so,uams_guest.so,uams_clrtxt.so 


volsizelimit:63 


-addr 65280.42 


erransal le namlrern 


Demo- oder Schulungs-CD aus. Viele Ein- 
stellungen lassen sich nämlich sehr gut mit 
den Original-Tools von Novell ändern, bei- 
spielsweise mit SYSCON, dem liebsten 
Haustier jedes Netware-Supervisors. Be- 
nutzer und Gruppen lassen sich in bekann- 
ter Manier bearbeiten, auch die 
Serverüberwachung oder ein Shutdown 
funktionieren wie gewohnt. Hier zeigt sich, 
dass die Unterstützung der NCP Calls 
schon recht weit gediehen ist — unter an- 
derem sind bereits Rechtevergaben inner- 
halb von Volumes in Form von Trustees 
möglich. 


NFS nutzen 


UNIX-Betriebssysteme haben in der Re- 
gel keine Schwierigkeiten, auf die Exports 
des NFS Servers zuzugreifen. Das expor- 
tierte Verzeichnis lässt sich einfach auf ei- 
nen beliebigen Mountpoint montieren, 
beispielsweise nach /mnt: 
mount -tnfs supernos:/var/share 
/mnt 

Der Name "supernos" muss dabei ent- 
weder lokal in der /etc/hosts Tabelle ein- 
getragen sein oder sich über den DNS 
Server des heimischen Netzes auflösen 
lassen. Notfalls funktioniert aber auch die 
IP Adresse anstelle des Namens. Sollte 
dennoch ein Fehler auftreten, so fehlen 
vielleicht die NFS Funktionen. Bei vielen 
Linux-Distributionen sind diese Bestandteil 
der Pakete „nfs-client" oder „nfs-util" und 
müssen explizit installiert werden. Auch 
Sun Solaris, Hewlett Packards HP-UX oder 
NeXTSTEP greifen so auf unser SuperNOS 
zu. Probleme bereiteten dem Autor bisher 
nur Clients mit IBM AIX, die partout keine 
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Er} Auswahl 
] | Wählen Sie einen File Server: 


© 
asupernos 


Server IP Adresse... 


® Aktiviert 
O Deaktiviert 


AppleTalk 
D1-7.55 


Das Feld Auswahl zeigt den Server 


Exports nutzen wollten. Die Ursache kon- 
nte bisher nicht geklärt werden. 


SMB Clients unter Windows 


Der Zugriff auf Samba sollte unter Win- 
dows die kleinsten Probleme bereiten, weil 
die Netzfunktionen spätestens seit Win- 
dows 95 tief in das System integriert sind. 
Der Client muss TCP/IP kennen und das 
Protokoll muss richtig konfiguriert sein. Au- 

i ßerdem muss er der Arbeitsgruppe SU- 
PERNOSGROUP angehören und den 
SuperNOS Server als WINS Server nut- 
zen. In der Netzwerkumgebung sollte un- 
ter den Windows Netzwerken dann diese 
Gruppe mit dem Server SMBSUPERNOS 
auftauchen. Wenn dies manchmal nicht der 
Fall ist, klappt die Namensauflösung über 
DNS und WINS nicht richtig. Die pragma- 
tische Lösung besteht in einem statischen 
Eintrag der IP Adresse und des Namens 
des SuperNOS Servers in der Datei \win- 
dows\imhosts. Bei Windows NT ist dies 
\windows\system32l\etc\Imhosts. Wenn al- 
le Stricke reißen, hilft meist eine Zuweisung 
eines Laufwerksbuchstabens zum Share 
in UNC Notation, hier also \\smbsuper- 
nos\share. 


OS/2 und SMB 


Am besten funktioniert der Zugriff auf den 
Server aus einem OS/2 Fenster heraus. 
Der Befehl net steht hier in ähnlicher Wei- 
se zur Verfügung wie unter MSDOS. Um 
Zugriff auf das freigegebene Verzeichnis 
auf dem Server zu erhalten, genügt also 
das folgende Kommando: 

net use g: \\smbsuper- 
nos\share 

Die Workplace Shell hat allerdings oft 
Schwierigkeiten mit derart zugeordneten 
Laufwerken. Besser klappt es mit einem al- 
ternativen Dateimanager wie File Freedom 
(siehe Links). Wer häufig zwischen Be- 
triebssystemen hin- und her wechselt, wird 
das zweigeteilte Fenster mit Baumansicht 
und Dateibereich sowieso hakeligen Arbeit 
mit der Workplace Shell vorziehen. 


Macintosh Clients 


Vom Macintosh aus ist es recht einfach, 
den SuperNOS Server zu nutzen. Apple- 


Am File Server supernos registriert als: 


O 6ast 
@® Registrierter Benutzer 


Name: user 
Kennwort: fe] (Text) 


Abbrechen Kennssort Andern 


D1-3.7.4 


Netatalk fragt die Benutzerdaten ab 


talk muss dazu über die Ethernet-Schnitt- 
stelle laufen, die Einstellung erfolgt im 
Kontrollfeld „Appletalk". Rechner ohne ein- 
gebautes Ethernet haben es hier natürlich 
schwer. Sie sind nur ins Netz zu bekom- 
men, wenn es entweder einen Macintosh 
mit laufender LocalTalk Bridge- Software 
im Netz gibt oder ein externer Ethernet Ad- 
apter angeschlossen wird. Entsprechende 
Adapter der Hersteller Farallon oder Asant& 
gibt es für die SCSI Schnittstelle oder für 
die serielle Schnittstelle. Allerdings sind 
diese Teile mittlerweile rar geworden. Eine 
Alternative ist der RaSCSI Adapter, der zu- 
sammen mit einem Raspberry Pi sowohl 
eine SCSI Festplatte als auch einen ent- 
sprechenden Adapter emulieren kann. 

Hängt der Mac erst einmal am Netz, so 
ist der Rest schnell gemacht. Im Kontroll- 
feld „Auswahl" (Chooser) findet sich unser 
Server unter dem Icon "AppleShare". Nach 
erfolgreicher Anmeldung als Benutzer 
„user" bietet der Server die definierten Vo- 
lumes an und packt sie nach Anklicken auf 
den Desktop. 

Bei Macintosh System 6.x können Pro- 
bleme auftauchen, wenn das exportierte 
Volume sich als zu groß meldet. Daher ist 
in der Beispielkonfiguration ein Limit von 
63 MB eingetragen. Diesen Wert meldet 
Netatalk zwar an den Mac, er hat ansons- 
ten aber keine größenbeschränkende Wir- 
kung. Das Volume fasst soviel Daten, wie 
die Festplatte hergibt. 


MSDOS mit Netware Worksta- 
tion 

Damit der Zugriff von MSDOS aus funk- 
tioniert, braucht es einen Protokollstack mit 
LSL und das IPX Protokoll aus dem Client 
Kit (siehe Links) sowie den passenden 
Netzkartentreiber. Dieser sollte sich auf der 
Treiberdiskette zur jeweiligen Netzwerkkar- 
te finden. Für den Zugang von einem Cli- 
ent aus sind einige Tools erforderlich. Um 
nicht einen vorhandenen Novell NetWare 
Server plündern zu müssen, hat Martin Sto- 
ver ein getrennt erhältliches Paket mars_- 
dosutils.tgz mit einem unter DOS 
lauffähigen NET.EXE Programm erstellt. 
Dieses erlaubt die Anmeldung am Server 
und das Mapping von Ressourcen wie 
Laufwerken und Drucker. Die Dateien aus 


nn asupernos 


Wählen Sie ein File Server Volume: 


Markierte Volumes (X) werden beim 
nächsten Systemstart automatisch geöffnet. 


" Deaktiviert _. _ 


Zugriff auf das eingerichtete Verzeichnis 


diesem Archiv gehören in das Verzeichnis 
login unterhalb des definierten SYS Vo- 
lumes und stehen so bereits zur Anmel- 
dung zur Verfügung. Einige Hinweise zur 
Clientkonfiguration finden sich auch in der 
Beschreibung der MAR.S NWE Konfigura- 
tionsdatei. 


Fazit 


SuSE Linux auf diese Weise als Super- 
NOS für ein Retrocomputer Netz zu konfi- 
gurieren, ist vielschichtig, aber zu bewäl- 
tigen. Sofern ein Rechner miteiner Ethernet 
Schnittstelle ausgestattet ist, lässt er sich 
fast immer dazu bewegen, mit dem Server 
in Kontakt zu treten. Dabei sind Clients mit 
aktuellen Betriebssystemen oft schwieriger 
zu beherrschen als ältere Systeme. Je neu- 
er das System, desto mehr Sicherheitsfea- 
tures sind implementiert und desto 
schlechter kommen die betagten Program- 
me von SuSE 9.1 mit diesen Mechanismen 
klar. Doch für Freunde alter Maschinen 
kann das selbst gebaute SuperNOS vieles 
leisten, da es den Datenaustausch deut- 
lich erleichtert. Es lohnt sich also, ausge- 
hend von diesem Artikel in eigene Experi- 
mente einzusteigen und das eigene System 
zu optimieren. (gb) 


Links 


SuSE Linux 9.1 
ftp.//ftpd.gwdg.de/pub/linux/suse/ 
discontinued/i386/9.1 

Dokumentation zu SuSE Linux 
https://www.novell.com/de-de/ 
documentation/suse/pdfdoc/ 
SuSE-Linux-Adminguide-9.0.0.0x86.pdf 
https://www-ux- 
sup.csx.cam.ac.uk/pub/doc/suse/ 
suse9. 1/adminguide9. 1/ 

Novell Netware Clients 
https://www.systemhaus- 
brandenburg.de/download/treiber/ 
novell/novell.html 
http:/files.mpoli.fi/hardware/NET/ 
NOVELL/CLIENTKT.ZIP 

OS/2 File Freedom 
https://hobbes.nmsu.edu/ 
download/pub/os2/util/browser/ 


FileFreedom_2-02.zip 
Ss Konfigurationsbeispiele 
@ und Software finden sich auf 
—y der Heft-CDROM 


Joystick-Anschluss als Analog/Digitalwandler nutzen 


Temperaturfühler 
am Apple ][ 


Der Apple Il eignet sich nicht 
nur aufgrund seiner Slots 
-die sich der IBM PC übri- 
gens vom Apple Il abge- 
schaut hat- zum Basteln 
eigener Erweiterungen. 
Auch sein Paddle- oder Joy- 
stick-Anschluss taugt für 
Basteleien. 


r besitzt einige 1 Bit Ein- und Aus- 

gänge, die wir hier aber nicht be- 

nötigen und deshalb nicht weiter 
betrachten. Interessanter ist etwas ande- 
res: Es stehen an diesem Anschluss sage 
und schreibe 4 Analog-Anschlüsse zur Ver- 
fügung. Jeder dieser Analogports hat eine 
Auflösung von 8 Bit, kann also 256 ver- 
schiedene Werte liefern. Einen kleinen Ha- 
ken hat die Sache aber schon — Spannung 
lässt sich nicht direkt messen, sondern nur 
der Widerstand. Übrigens besitzt auch der 
Commodore 64 diese Fähigkeiten, bietet 
jedoch im Gegensatz zum Apple keine BA- 
SIC-Befehle zum Auslesen. Dort muss der 
Nutzer mit PEEK und POKE arbeiten. 

Um eine Temperatur messen zu können, 
braucht es ein Bauteil, das mit steigender 
Temperatur seine Eigenschaften ändert. 
Das ist idealerweise der Widerstand, denn 
den kann der Apple Il messen. Dazu gibt 
es zwei Sorten: Heiß- und Kaltleiter, auch 
als NTC und PTC bezeichnet. Heißleiter 
(NTC) leiten mit steigender Temperatur im- 
mer besser, Kaltleiter (PTC) leiten im kal- 
ten Zustand besser als bei hohen 
Temperaturen. Prinzipiell sind beide Sor- 
ten zu verwenden -- ich hatte gerade ein 
paar NTC verfügbar und habe deswegen 
Heißleiter verwendet. Egal, ob NTC oder 
PTC, der Widerstandsbereich ist in beiden 
Fällen zu beachten. Der Apple Il erkennt 
Widerstände von Null bis 150 kOhm. Bei 8 
Bit sind das 256 Möglichkeiten und das er- 
gibt wiederum eine Schrittweite von etwa 


849U Ohm. Als Kennwert wırd ım Handel der 
R25 angegeben, das ist der Widerstand bei 
25 Grad Celsius. Mein NTC hat den Wert 
R25 = 50 kOhm und eine flache Kennlinie. 
Vorsicht bei NTCs, die als Begrenzung für 
Einschaltströme eingesetzt werden: Sie ha- 
ben eine steile Kennlinie und eignen sich 
nicht für dieses Projekt. Mein NTC-Sensor 
hat bei -18 Grad in der Gefriertruhe einen 
Widerstand von 170 kOhm, was der Apple 
als Maximalwert erkennt. Bei steigender 
Temperatur sinkt der Widerstand, der Ap- 
ple liefert also kleinere Messwerte bei stei- 
gender Temperatur. 

Wie wird der NTC nun am Apple ange- 
schlossen? Dazu betrachten wir die Pinbe- 
legung des GAME I/O Ports: 


Apple Il Joystick Pinout 


+bY 

PBO 
PB1 

PB2 
STB 
GCO 
Gc2 
GND 


1 
2 
3 
4 
5 
6 
7 
8 


Von Interesse sind hier die Anschlüsse 
GCO bis GC3, besonders GCO und GC1. 
Wir verbinden den einen Pol des NTC mit 
GCO (Pin 6), den anderen mit + 5 Volt (Pin 
1). Und damit sind wir schon fertig. Wer 
mag, kann noch einen zweiten Sensor zwi- 
schen GC1 und +5V anschließen. Das 
kann beispielsweise ein zweiter Tempera- 
tursensor oder ein lichtempfindlicher Wi- 
derstand (LDR) sein. 


Ich habe zwei Temperatursensoren und 
relativ lange Kabel verwendet, damit ich In- 
nen- und Außentemperatur messen kann. 
Die Kabellänge ist unkritisch, bei 150 KOhm 
Maximalwert machen 2 oder 3 Ohm Kabel- 
widerstand keinen beachtenswerten Unter- 
schied. Wir erinnern uns: Die Schrittweite 
beträgt 590 Ohm. 

Nun geht es an die Softwareseite: PRINT 
PDL(0) zeigt den Wert von GCO an (PDL(1) 
entsprechend GC1). Ein erstes kleines 
Testprogramm ist ein Zweizeiler: 


10 Print PDL(0), 
0 EOME) 110) 


PDL(1) 


Nun schreibt der Apple nach einem be- 
herzten RUN zwei Zahlenreihen fortlaufend 
auf den Schirm. Wer nur einen Sensor 
verbaut hat sieht als zweite Zahl immer die 
255. Bei zwei identischen Temperatur- 
sensoren zeigen beide Sensoren die 
gleichen Werte an. Liegt ein Sensor in der 
warmen Hand, sinken die Werte. Der Wert 
255 bedeutet sehr kalt, der Wert O sehr 
warm. Mögliche Erweiterungen des Test- 
programms wären beispielweise ein Tem- 
peraturlog und eine Speicherung der Werte 
auf Diskette. Dann empfiehlt sich aber eine 
Warteschleife zwischen Zeile 10 und 20, 
um nur etwa jede Sekunde einen Wert zu 
lesen. Zur Auswertung ließe sich dann ein 
extra Programm schreiben, um den Verlauf 
in der HiRes-Grafik darzustellen. 

Allerdings kann das Programm bis jetzt 
nur relative Temperaturänderungen mes- 
sen. Um von Widerstandswerten auf Tem- 
peraturen zu kommen, braucht es eine 
Kalibrierung des Sensors und eine Um- 
rechnung der Werte in konkrete Tempera- 
turen. Hier lohnen sich eigene Experi- 
mente. In Teil 2 dieses Artikels stellen wir 
hierzu einige interessante Ansätze vor. 


Software 


Plattformübergreifende Programmentwicklung 


Atari ST Cross- 
Entwicklungsumgebung 


Ein Cross-Compiler läuft auf einem bestimmten System, 
kompiliert aber Objektdateien oder ausführbare Program- 
me für andere Systeme. Das können andere Betriebs- 
systeme, andere Prozessoren oder eine Kombination der 
beiden sein. Wir zeigen hier, wie ein Cross-Compiler un- 
ter Linux, Windows oder Mac OS X helfen kann, um Pro- 
gramme auf den Atari ST zu portieren. 


ür eine plattformübergreifende 

Entwicklung braucht es im we- 

sentlichen zwei Dinge. Zunächst 
ist natürlich ein Compiler erforderlich, der 
die benötigte Programmiersprache verar- 
beitet und an einen Assembler übergibt, 
der Binärcode für die Zielplattform erzeu- 
gen kann. Hier bedeutet das, Compiler und 
Assembler müssen auf einer Intel-Plattform 
Binärcode für den Motorola 68000 erstel- 
len können. Das allein reicht aber nicht aus: 
Programmiersprachen wie C und C++ stüt- 
zen sich auf Standardbibliotheken, in de- 
nen die Funktionen der jeweiligen Pro- 
grammiersprache realisiert sind. Im Falle 
einer Entwicklung in C unter Linux ist es 
die GNU glibc. Außerdem braucht es wei- 
tere Bibliotheken für ergänzende Funktio- 
nen wie Grafikdarstellung oder Netzzugriff. 
Sie werden zum eigentlichen Ergebnis ei- 
nes Compilerlaufs hinzugefügt; dies über- 
nimmt ein spezielles Programm, der Linker. 
Bei einer Cross-Entwicklung sind auch die- 
se Bibliotheken in einer 68000er Version 
erforderlich und der Linker muss mit die- 
sen umgehen können. 


GNU GCC 


Die Suche nach einem passenden Com- 
piler für eine Cross-Entwicklung führt meist 
zur GNU Compiler Collection, GNU GCC. 
Hierbei handelt es sich um freie Software 
aus dem GNU Projekt. Seine Geschichte 
reicht weit zurück. Begonnen hat sie mit 
dem GNU C Compiler, vom Urvater der 
Idee freier Software, Richard M. Stallmann 
1987 selbst freigegeben. 1997 spaltete sich 
aus der Entwicklung dieses Compilers das 
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EGCS Projekt ab. Es verfolgte das Ziel, be- 
stehende und eher experimentelle Abspal- 
tungen aus dem GCC Projekt wieder zu 
vereinen und eine Compiler Collection zu 
schaffen, die neben C auch C++, Fortran 
und andere Programmiersprachen unter- 
stützt. Im Jahr 1999 vereinigten sich EG- 
CS und das ursprüngliche GCC Projekt 
wieder und seitdem wird die GNU Compi- 
ler Collection in der heute erhältlichen Form 
gepflegt. GCC unterstützt heute die Pro- 
grammiersprachen C, C++, Objective-C, 
D, Fortran, Ada und Go und kann Code für 
verschiedenste Plattformen erzeugen, ne- 
ben Intel-Prozessoren auch für Motorola-, 
ARM und diverse Workstation-CPUs und 
deren Betriebssysteme, aber auch für ein- 
gebettete Systeme. Auf vielen Plattformen 
ist der GCC "self hosted", kann also seinen 
eigenen Quellcode für die Zielplattform 
kompilieren. 


Vincent Riviere's 
m68k-atari-mint cross-tools 
Etwas mehr Aufwand braucht es bei der 
Suche nach der zweiten Komponente für 
die Cross-Entwicklung, nämlich die erfor- 
derlichen Bibliotheken. Hier empfiehlt sich 
ein Blick auf die Webseite von Vincent Ri- 
viere, in der Atari ST Szene unter anderem 
durch seine Arbeit an EmuTOS und der 
Firebee bekannt. Dort finden sich Compi- 
ler und Build-Umgebungen für Microsoft 
Windows, verschiedene Linux Distributio- 
nen und für Mac OS X. Normalerweise ar- 
beitet der Autor unter Linux Mint 20.1 mit 
Hatari 2.3.1 als AtariST Emulator. Die Um- 
gebung wurde aber auch erfolgreich mit Mi- 


crosoft Windows 10 und mit Mac OS X 
Mojave und Catalina getestet. Neben den 
erforderlichen Bibliotheken bringen die 
Cross Tools auch den kompletten Compi- 
ler und Assembler mit. m68k-atari-mint-as 
oder kurz GAS ist dabei der von Vincent 
Riviere bereitgestellte bereit gestellte As- 
sembler. Er wandelt eine Assembler-Quell- 
datei des Compilers in eine binäre Objekt- 
datei um. Dieser erzeugt Binaries in einem 
Format für TOS und nicht im Binärformat, 
das für den TOS Nachfolger MiNT (nicht zu 
verwechseln mit dem Ubuntu-Abkömmling 
Linux Mint) spezifiziert wurde. 


Umgebung unter 
Linux installieren 


Die Installation unter Linux Mint 20.1 ver- 
läuft recht einfach, denn Vincent Riviere 
stellt ein "personal package archive" (PPA) 
bereit. Ein PPAist ein Service der Software- 
plattform Launchpad, die von Canonical als 
Unternehmen hinter Ubuntu betrieben wird. 
Es bietet die Möglichkeit, Debian-Pakete 
für unterschiedliche Architekturen und für 
unterschiedliche Ubuntu-Versionen zu 
bauen. 

Zunächst muss unter Linux Mint 20.1 
das PPA registriert werden: 

sudo add-apt-repository 
ppa:vriviere/ppa 

Anschließend wird die Paketverwaltung 
aktualisiert: 

sudo apt update 

und die eigentliche Cross-Entwicklungs- 

umgebung installiert: 
sudo apt install cross-mint- 
essential 

Der Erfolg lässt sich wie üblich mit einem 
kleinen "Hello World" Programm prüfen: 

m68k-atari-mint-gcc hello.c 
-o hello.tos 

Die so übersetzten Programme werden 
allerdings ziemlich groß (Script 1), das 
"Hello World" Kompilat nimmt bereits 
174.580 Bytes. Das hat einen Grund: 
Standardmäßig linken gec-kompilierte Pro- 
gramme auf der Atari ST-Plattform auf mint- 
lib. Mintlib zielt darauf ab, alle POSIX- 
Funktionen zu implementieren, um die Por- 
tierung von Unix/Linux-Programmen zu er- 
leichtern Für kleine TOS und GEM-basierte 
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16MH2/020<CE) /68881 14MB Falcon. T0OS 4.04. VGA 50 Hz 
A: B:M HD:M SE:18 00:00:01:0 -—--—— FS: 0 BLT:MREC:M 


Pong läuft im Atari-Emulator Hatari 


Programme hat dies jedoch den Nachteil 
einer entsprechenden Programmgröße. 
Deutlich kleiner werden die Binaries mit der 
libcmini von Thorsten Otto (Script 2). lib- 
cmini zielt darauf ab, eine C-Bibliothek mit 
geringem Platzbedarf für die m68k-atari- 
mint (cross)-Werkzeugkette zu sein, ähn- 
lich der C-Bibliothek, mit der Pure-C 
geliefert wurde. Viele TOS und GEM-Pro- 
gramme benötigen nur eine Handvoll C- 
Bibliotheksfunktionen und nicht die volle 
POSIX Unterstützung der mintlib. Gegen 
diese Bibliothek kompiliert nimmt das "Hello 
World" Kompilat nur noch 2.722 Bytes ein. 
Um die erzeugten Programme zu testen, 
braucht es nicht zwangsläufig einen voll- 
ständig installierten Atari ST Emulator. Viel- 
mehr bietet TOSEMU von Paul Wratt einen 
einfachen Weg, ein TOS Binary auf Linux 
laufen zu lassen. TOSEMU fängt Betriebs- 
systemaufrufe ab und emuliert diese auf 
der Host-Plattform. Das Prinzip ist Linux- 
anwendern sicher bereits von WINE bekan- 
— diese Software erlaubt es, Windows 
Binaries direkt auf Linux auszuführen. 


Simple DirectMedia Layer 


Programme im Textmodus lassen sich 
so recht zuverlässig kompilieren, sofern die 
passenden Bibliotheken bereitstehen. 
Spannend wird es, sollen auch grafikba- 
sierte Programme wie Spiele portiert und 
in der Cross-Entwicklungsumgebung kom- 


| 

Seript 1: 

/Bin/sh — 
k-atari-mint-gce $1.c -o 
.tos 

k-atari-mint-strip $1.tos 


I 
ee 22 2) 2 
in/sh 

k-atari-mint-gece -nostdlib 
\ibemini/lib/ert0.o $1.c -o 

os -s -Llibemini/lib/ -Icmini 


(&& 
| 
\ Script 3: 
in/sh 
k-atari-mint-gce $1.c -o 


= rg -L- /usr/m68k-atari- 
nt/lib -1SDL -Igem 
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Ein einfaches SDL Programm 


piliert werden. Bisherige Versuche des Au- 
tors haben sich auf SDL- basierte Pro- 
gramme beschränkt. SDL (Simple Direct 
Media Layer) ist eine plattformübergreifen- 
de Entwicklungsbibliothek, die den Low-Le- 
vel-Zugriff auf Audio-, Tastatur-, Maus-, 
Joystick- und Grafikhardware ermöglicht. 
Einerseits macht der plattformübergreifen- 
de Ansatz SDL besonders reizvoll, für den 
Atari ST zeigen sich jedoch einige Nach- 
teile: 


Nutzbar ist für die Cross Entwick- 
lung nur SDL1 und nicht SDL2. 
SDL Programme sind sehr lang- 
sam und daher nur für schnelle 
Rechner wie den Falcon und wenig 
bewegte Grafik geeignet. 

SDL Programme sind sehr groß, da 
die komplette Lib dazu gelinkt wird. 
Ohne die Zusatzbibliothen SDL_I- 
mage können nur BMP Grafikdatei- 
en verarbeitet. werden. Der 
Versuch, die SDL_Image Lib und 
weitere benötigte Bibliotheken von 
Thorsten Otto einzubinden, miss- 
lang allerdings bisher. 


Zwei Spiele ließen sich jedoch gut über- 
setzen, zum einen Snake und zum ande- 
ren Pong. Script 3 zeigt den Compileraufruf. 
Bei Pong gab es einen nicht untypischen 
Fehler. Das Binary lief auf dem emulierten 
AtariST unter Hatari aber nicht auf einem 
echten Falcon. Die Ursache: Eine Bildda- 
tei mit dem Namen numbermap.bmp. Ha- 
tari unterstützt lange Dateinamen, dadurch 
konnte die Datei unter Linux gefunden wer- 
den. Auf dem Atari Falcon ist aber nacktes 
TOS vorhanden, das nur 8.3 Dateinamen 
kennt. Bei Portierungen lohnt es sich also, 
genau in den Quellcode zu schauen. 

Gegen die vorkompilierte SDL Bibliothek 
gelinkte Programme ließen sich jedoch 
nicht auf einem 1040ST zum Laufen brin- 
gen. Das legt den Verdacht nahe, dass die 
Bibliothek Code für den Motorola 68020 
enthält. Eine genaue Klärung steht noch 
aus. 


uw 
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Farb-Demo in SDL 


Aber auch mit nur der reinen SDL lib ist 
viel zu machen. Texte lassen sich mit Bit- 
map Fonts ausgeben und selbst Sound 
geht ohne SDL_mixer. Ein kleines Beispiel 
findet sich im GitHub Repository des Au- 
tors. Da es sich um reines C und SDL han- 
delt und nichts Atari Falcon spezifisches 
darin vorhanden ist, lässt es sich auf und 
für jedes System kompilieren, welches den 
(Cross)GCC und die LibSDL zur Verfügung 
stellt (ps). 


Links: 


http://vincent.riviere.free.fr/soft/m68k-atari-mint/ 
https://tho-otto.de/crossmint.php <- win32 
https://github.com/freemint/libcmini 
https://github.com/paulwratt/tosemu 
https://www.parallelrealities.co.uk/tutorials/sdl1/ 
https://lazyfoo.net/SDL_tutorials/ 
http://gamedevgeek.com/tutorials/moving-spri- 
tes-with-sal/ 
https://members.loria.fr/PGaudry/static/Metho- 
do/animating-sprites.html 
https://gist.github.com/armornick/3447121 
https://github.com/driedfrui/SDL_inprint 

Snake: 

https://gist.github.com/cellularmito- 
sis/6e54ea6d0965bff16ac947c19bc06d3c 
Pong: 

https://github.com/zotherstupidguy/pong 
Beispiel: 
https://github.com/petersieg/Simple-SDL-Demo 


x Programmbeispiele finden 
“> sich auf der Heft-CD 


Software 


Programme unter Linux assemblieren 


Atari ST Cross 
Assembler 


Github hat sich als Austauschplattform für verschiedenste 
Projekte etabliert und auch nach der Übernahme durch 
den Branchenriesen Microsoft nicht an Attraktivität 
eingebüßt. In den Repositories von Github finden sich 
aber beileibe nicht nur Quelltexte zu aktueller Software. 


ie Plattform wird auch genutzt, 

um Quellen der Software für Ret- 

rocomputer zu archivieren. Eines 
dieser interessanten Projekte ist das Atari 
ST source code repository von Github-User 
"ggnkua". Dort sind Quellcodes in Assem- 
bler, C, GFA Basic, Omikron Basic und Pas- 
cal ebenso zu finden wie Dokumentationen 
und TOS Quellcodes. 

Der Zweig der Assemblerquellen eignet 
sich hervorragend für eigene Experimente. 
Recht einfach wäre es, die Quellcodes mit 
einem Assembler auf dem Atari selbst zu 
assemblieren. Doch nachdem der Aufbau 
einer Crossentwicklungsumgebung für C- 
Code auf dem PC bereits viel Spaß 
gemacht hat, war es naheliegend , auch 
die Assemblerprogramme auf diesem Weg 
zu übersetzen. Als Assembler lässt sich 
dafür der VASM unter Linux Mint 20.1 
nutzen. Auch der Test der Programme er- 
folgte aus Bequemlichkeit gleich auf dem 
Linuxrechner, hier diente Hatari 2.3.1 mit 
den jeweiligen Einstellungen für ST-RGB, 
Mono und STE-RGB als Testumgebung. 
Auch ein echter Atari ST kam zum Einsatz, 
wenn sich das Binary als prinzipiell lauffähig 
erwiesen hatte. 

Um geeignete Programme zu finden, 
wurde der Assembler-Zweig des Reposit- 
ory ausführlich durchforstet und Spreu vom 
Weizen getrennt. Schnell wurde klar, dass 
es sich lohnt, für geeignete Programme ei- 
nen eigenen Verzeichnisbaum anzulegen. 
Dieser sollte nur Quelltexte enthalten, die 
sich auch assemblieren ließen und das Pro- 
gramm danach auch lief. Das klappte nicht 
ohne Veränderungen an den Quellen. So 
mussten fast überall absolute Pfade bei IN- 
CBIN angepasst werden. Einige Unter- 
verzeichnisse im Repository waren außer- 
dem leer. Bei einigen Programmen ließen 
sich die Quellen nicht Cross-assemblieren, 
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manchmal lief ein scheinbar fehlerlos as- 
sembliertes Programm nicht. 

In den Unterverzeichnissen der auf diese 
Weise ausgesiebten Quellcode-Sammlung 
ist die Hauptquelldatei jeweils auf main.s 
kopiert und gegebenenfalls angepasst. Der 
Assemblerlauf wird mit 


./vasm -Ftos -tos-flags=1 
main.s -o main.tos 


gestartet. Das fertige Binary main.tos fin- 
det sich dann in diesem Unterverzeichnis. 

Einige besonders interessante Pro- 
gramme seien hier kurz erwähnt: 


Cubemap zeigt einen drehenden 
Würfel mit einem Bild 

Life ist eine Implementierung der 
bekannten "Life" Simulation für ST- 
Mono 

Im Verzeichnis O finden sich einige 
kurze Demos sowohl für VASM als 
auch für GenST Assembler. Die dort 
assemblierten Binaries haben die 
Endung *.PRG 


Cubemap 


32 kByte Demo 


In den Links am Ende des Artikels wird 
auf weitere Seiten verwiesen, die Tipps 
oder Tools und auch weitere Quellen für 
kurze Demos liefern. Insbesondere die 
DHS Demosysteme für ST und Falcon sind 
mehr als einen Blick wert. 

Das Ausprobieren macht jedenfalls viel 
Spaß und vielleicht fühlt sich der eine oder 
andere Leser ja motiviert, in die Program- 
mierung von Intros oder Demos in Assem- 
bler für den Atari ST oder Falcon einzu- 
steigen. Wenn dieser kleine Artikel darauf 
Appetit gemacht hat, so ist sein Zweck er- 
füllt. (ps) 


Links 


Das Atari ST source code repository 
https://github.com/ggnkua/Atari_ST_- 
Sources 

VASM 

http://sun.hasenbraten.de/vasm/ 

Tools und Tipps 

httos://dhs.nuffiles.php ?t=single&ID=138 
https://nguillaumin.github.io/perihelion- 
m68k-tutorials/ 

Winzige Demos 
http://www.sizecoding.org/wviki/Motoro- 
la_68k_based_CPUS 

DHS Demosysteme 


https://www.dhs.nu/ 
< Das Verzeichnis mit den 
Ar 


\, ausgewählten Quellen 
"findet sich auf der Heft-CD. 


Der Klassiker der Datenbanken 
Einstieg in 
dBASE 


dBASE war das erste weithin genutzte 
datenbasierte Datenbankmanagement- 
system (DBMS) für Mikrocomputer. Es 
wurde von dem Unternehmen Ashton-Tate 
ursprünglich für das Betriebssystem CP/M 
entwickelt und vertrieben. Später wurde die 
Datenbankapplikation auf den IBM-PC 
unter DOS portiert. 


Propulsion Laboratory der NASA wurde damals ein Sys- 

tem namens RETRIEVE verwendet. Dieses wurde durch 
mehrere Personen im Laufe der Zeit angepasst, so letztendlich 
auch von einem Mann namens Wayne Ratliff. Dieser nannte sei- 
ne Fortentwicklung VULCAN, Name des Heimatplaneten von Mr. 
Spock aus Star Trek. 


S einen Ursprung hat dBASE in den 1960er Jahren. Im Jet 


Wechselvolle Geschichte 


Ashton-Tate kaufte die Rechte an VULCAN und stelle auch die 
Entwickler dazu ein. Die Entwickler portierten VULCAN auf das 
Betriebssystem CP/M und Ashton-Tate nannte es dBASE Il. Es 
gab keine „Version |. 

dBASE || war sehr erfolgreich, also wurde es auch auf andere 
8-Bit System weiter portiert, z.B. Apple II (CP/M mit Z80-Prozes- 
sor-Karte). Später erschien auch eine Version für Atari ST. Im Au- 
gust 1932 veröffentlichte Ashton Tate eine 16 Bit Version für IBM 
PC unter dem Namen dBASE Il 2.3. dBASE wurde zum erfolg- 
reichsten PC-Datenbanksystem der 1930er Jahre. 

Die Weiterentwicklungen waren in der zweiten Hälfte der 1980er 
Jahre die Releases dBASE Ill und dBASE Ill (plus). Hierbei wur- 
den auch die neuesten Trends der PC-Technik berücksichtigt, wie 
Netzwerktechnologie mit Mehrplatznutzung oder die Integration 
von Schnittstellen zu Lotus 1-2-3 und MS-Word. 

Im Jahre 1988 erschien dann dBASE IV. Asthon-Tate hatte hier 
viel investiert und versuchte, weitere moderne Konzepte einzu- 
bauen. Letztlich scheiterte diese Version jedoch an technischen 
Hürden wie der 640 KB Grenze. DBASE IV erwies sich als sehr 
langsam und einige Komponenten als schwer zu bedienen. Der 
Erfolg blieb aus und 1991 kaufte schließlich Borland das ange- 
schlagene Unternehmen Asthon-Tate. Borland hatte bereits ein ei- 
genes PC-Datenbank System namens PARADOX, doch das konnte 
nicht mit dem Erfolg von dBASE mithalten. Borland führte dBASE 
daher unter angepasstem Namen weiter und verkaufte es als Bor- 
land dBASE, dBASE for Windows und Visual dBASE. 

Die Besitzverhältnisse von dBASE änderten sich im Laufe der 
Jahre weiter. Anfang der 2000er Jahre wurden die Rechte an ei- 
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ASHTON-TATE 


ne Firma dBASE Inc. verkauft und im Jahr 2005 wanderten die 
Rechte an DataBased Intelligence Inc. weiter. Die Firma vermark- 
tet es unter dem Namen dBASE plus. Der letzte Verkauf erfolgte 
im Jahre 2012 an die neu gegründete Firma dBASE LLC, die bis 
heute dBASE weiterentwickelt und verkauft. 


Erste Schritte mit dBASE 


Die Grundidee von dBASE ist es, eine relationale Datenbank 
gepaart mit einer Programmiersprache der vierten Generation in 
einer speziellen strukturierten Datei zu halten. Die dort entwickel- 
te Syntax und das verwendete Datenbankformat (DBF) haben über 
Jahrzehnte den Bereich der desktopbasierten PC-Datenbank Sys- 
teme beeinflusst und bestimmt. Dieser Artikel zeigt exemplarisch 
die Schritte beim Entwerfen und Implementieren einer Datenbank. 
Die Schritte wurden auf einem IBM PC mit MS-DOS durchgeführt 
und lassen sich mit den Versionen dBASE II und Ill plus leicht 
nachvollziehen. 

Die Arbeit beginnt in der Regel mit dem Entwurf eines Daten- 
bankmodells der gewünschten Applikation unter Berücksichtigung 
der passenden Normalform. Zuerst legt der Benutzer also die Ta- 
bellen an, definiert dann die Indizes, Views und Reports und kann 
schließlich Programmcode integrieren, um weitere Funktionen und 
eine Oberfläche zur Verfügung zu stellen. 

Das Programm dBASE wird unter MS-DOS einfach durch den 
Aufruf von dBASE gestartet. 


C:NDBASE3P>Abase 
DBASE begrüßt den Anwender und zeigt dann den dBASE As- 


sistenten, der ab dBASE Ill vorhanden ist und eine Oberfläche im 
MS-DOS Menü Stil besitzt. 


dBASE III PLUS Version 1.1 
This Software is Licensed to: 


Copyright (c) Ashton-Tate 1985, 1986. All Rights Reserved. 
ABASE, dBASE III PLUS and Ashton-Tate are trademarks of Ashton-Tate 


You may use the software and printed materials in the dBASE III 
PLUS package under the terns of the Software License Agreement: 
please read it. In summary, Ashton-Tate grants you a paid-up, 
non-transferable, personal license to use dBASE III PLUS on one 
conputer work station. You do not become the owner of the 
package nor do you have the right to copy (except pernitted 
backups of the software) or alter the software or printed 
materials. You are legally accountable for any violation of the 
License Agreement and copyright, trademark, or trade secret law. 


Connand Line cc: >| U | j | 


Press 4-! to assent to the License Agreenent and begin dBASE III PLUS._ 


Zuerst wird eine Datenbank mit einer entsprechenden Struktur 
auf einem passenden Laufwerk erstellt. Der Name der Datenbank 
ist gleichzeitig auch der Name der Datenbank-Datei mit der En- 
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Software 


dung DBF, also z.B. Datenbank Name ist TRAVEL, der Name der 
Datenbank-Datei ist TRAVEL.DBF: 


Set Up Update Position Retrieve Organize Modify Tools EEERHENT] 
| Database file |If 


Format 
View 


Query 
Report 
Label 


Command: CREATE 


ASSIST |<Ce (———n [0,193 mu | ame |13... mm) 
Position selection bar - 1}. Select - 4-1. Leave menu - +». 


Select a disk drive to search. 


Dann wird die Struktur mit folgenden Feldern definiert, hier un- 
ten im Beispiel die Tabelle TRAVEL für die Verwaltung von Reisen: 


Bytes remaining: 3864 
CURSOR <-- --> INSERT DELETE Up a field: t 
Char: a Char: Ins Char: Del Down a field: + 
Word: Home End Field: “N Word: ”°Y Exit/Save: “End 
Pan: Ne rs Help: Fi Field: “U Abort: Esc 
Field Nane Type Width Dec Field Name Type Width Dec 
Per IRSTNAME 1 9 AGENT Character 2 
2 LASINAME Character 20 10 RESERVDATE Date 8 
3 PHONE Character 13 11 NOTES Meno 10 
4 TRAUELCODE Character 4 
5 TRAVELPLAN Character 40 
6 DEPARTURE Date 8 
? c0ST Nuneric 10 2 
8 PAID Logical 2 
MODIFY STRUCTURE |<C:> [TRAVEL Field: 1/11 I —— 1 -——| 
Enter the field nane. 


Field names begin with a letter and may contain letters, digits and underscores 


dBASE lässt sich sowohl durch Menüs als auch durch Befehle 
auf der Kommandozeile bedienen. Mit ESC kommt der Benutzer 
vom Menü-basierten Assistenten zur Kommandozeile und mit dem 
Kommando ASSIST wieder zurück zum Assistenten. Über die 
Kommandozeile wird die Datenbank mit dem Befehl USE ausge- 
wählt, die Anzeige der Datenbankstruktur erfolgt mit dem Befehl 
LIST STRUCTURE: 


Copyright (C) 1982 RSP Inc. 


»®»* dBASE II/86 Ver 2:4 


. use client 


1 July 1983 


STRUCTURE FOR FILE: C:CLIENT .DBF 
NUMBER OF RECORDS: 00005 

DATE OF LAST UPDATE: 00/00/00 
PRIMARY USE DATABASE 


FLD NAME TYPE WIDTH DEC 
001 NAME c 030 
002 ADDRESS C 030 
003 WPHONE c 013 
004 HPHONE C 013 
005 PHPREF c 001 
** TOTAL x** 00088 


Zur Anzeige aller Daten wird der Befehl LIST ALL aufgerufen, 
das Ergebnis ist dann die Anzeige aller Datensätze. 


„List all 

00001 ALBERT EINSTEIN 
2 (201)555-1313 W 
00002 ROBERT REDFORD 
5 (213)555-1000 H 
00003 KILGORE TROUT 
0 (312)555-9999 W 
00004 BOB HOPE 

? (213)555-8888 H 
00005 RONALD REAGAN 
0 CLASSIFIED H 


LITTLE TOWN USA (201)555-12 


LOS ANGELES CA. (213)555-05 
NOUHERE (312)555-00 
TOLUCA LAKE CA. (213)555-77 


WASHINGTON DC (212)555-50 


Wenn die Datenbankstruktur dann geschaffen ist und die ers- 
ten Daten eingegeben wurden, sieht das Ganze im dBASE Assis- 
tenten so aus, hier der EDIT Mode (ein RECORD Anzeige): 


CURSOR ge #7 up DOUN DELETE Insert Mode: Ins 
Char: .> Field: t + Char: Del Exit/Saue: “End 
Word: Home End Page: PgUp PgDn Field: °Y Abort: Esc 

Help: Fi Record: “U Memo: “Home 


FIRSTNAME 
LASTNAME 
PHONE 
TRAVELCODE 
TRAVELPLAN 
DEPARTURE 
COST 

PAID 

AGENT 
RESERUDATE 
NOTES 


EDIT [7 <c:> TRAVEL [Rec: 1/43 || | 


Hier die Anzeige im BROWSE Mode des Assistenten: 


CURSOR un ; up DOWN DELETE Insert Mode: Ins 
Char: © Record: t + Char: Del Exit: “End 
Field: Home End Page: PgUp PgDn Field: *y Abort: Esc 
Pan: = Help: Fi Record: “U Set Options: “Hone 


EIBSTNANE-—————— LASTNAME--------—--—- PHONE 
IB [EEEPEETSEIEE SER) 


nn. TRAVELCODE 


Rick Lisbonn (555)455-3344 AV1O 
dank Bicksby (555)966-1278 KS19 
Lena Garnett (555)766-9121 GEZ3 
Lisa Kafmanan (555)860-0300 HI14 
Jay Johnson (555)860-6784 KS19 
3ara Collins (555)568-0953 HI14 
Rick Zanbini (555)345-1945 CI10 
kim Arlich (555)624-8773 JH10 
John Montovan (555)566-3403 KS19 
Jicky Gorenan (555)846-8801 WA8 
prouse _____[cc:>[rravEL [rec 179 1 0] 


View and edit fields. 


Dann beginnt im nächsten Schritt die Entwicklung von dBASE 
Code zur Erstellung von ausführbaren Programmen unter dBA- 
SE. Diese haben immer die Endung PRG. 

Im Wesentlichen beinhaltet die Sprache viele Elemente einer 
damals modernen Hochsprache der vierten Generation. Hierbei 
können sowohl Programme entwickelt werden, die etwas mit den 
Datensätzen an sich tun, aber es kann auch eine dialogorientier- 
te Anwendung entwickelt werden, welche den User über eine Dia- 
logoberfläche durch die Nutzung der Datenbank führt. 

Die Kommandos zur Pflege und Änderung von Datenbanken 
und Attributen sind im Code ebenso nutzbar wie von der Komman- 
dozeile in dBASE. 


. modify command checks.prg 


BTORE © TO DK 
DO UHILE OK = © 


IF ’&PROMPT’ # ’ 
ACCEPT ’&PROMPT’ TO COMMAND 


SE 
ACCEPT TO COMMAND 
ENDIF 
STORE ?CCOMMAND) TO COMMAND 
IF COMMAND = ’QUIT’ 
quit 
ENDIF 
IF COMMAND # CHECK 
DO CLEAR@ 
?"You didn’t enter” 
7"  &CHECK" 
?"Please try again.” 
LOOP 


LSE 
STORE 1 TO OK 
&c 


OMMAND 
ENDIF 
ENDDO 
STORE ’ 10 PROMPT 


Ein Programm wird gestartet mit dem Kommando DO. Als Mus- 
ter kann hier die mitgelieferte Anwendung lessons.prg dienen. 


C:\DBASEII>dbase 


Copyright (C) 1982 RSP Inc. 


If this is the first time you’ve used dBASE II LESSONS, select the 
I option from the menu below. This introduction contains background 
material on computers, operating systems, and dBASE II 


If this is not the first time you’ve used dBASE II LESSONS, select 
the appropriate lesson number (or QUIT) from the menu below. 


I - Introduction, definitions of basic computer terms (reference, 
not interactive) 
Create files, generate Reports, and correct syntax errors 
Add, change, and delete data in files, and record positioning 
Selecting sub-sets of data on files, and computations 
Record keys, indexing, random processing, and Boolean operators 
File and system utilities, and intro to comnand procedures 
Sorting, updating, and use of memory 
Relational data base construction 
Other forms of accepting and displaying data, dBASE II functions, 
and SET options 

9 - Building custom reports and screens 

10 - Command procedures (programming features in dBASE II) 
QUIT - In response to any pronpt, to return to the operating systen 


ENTER THE LESSON NUMBER: _ 


Fazit 


DBASE Datenbanken sind auch heute noch nutzbar, da viele 
moderne PC-Datenbanken wie beispielsweise Microsoft Access 
das DBF Format der dBASE Datenbankdateien unterstützen. Heut- 
zutage werden jedoch moderne Benutzeroberflächen im Web- 
browser oder unter Microsoft Windows genutzt, um mit dBASE 
Dateien zu arbeiten. 


httos://de.wikipedia.org/wiki/DBASE 


xx* dBASE II/86 Ver 2.4 1 July 1983 
. do lessons.prg Links 
Das Unternehmen hinter dBASE dBASE Il 


Ashton-Tate 


George Tate und Hal Lashlee gründeten das Unternehmen 
Ashton-Tate im Jahre 1980. Die erste Entwicklung war ein 
einfaches Programm für den Betrieb eines Fußball- 
Tippspiels im Büro. Mit der Übernahme der Vulcan- Daten- 
bank und der Weiterentwicklung zu dBASE wurde aus dem 
kleinen Softwarehaus ein multinationales Unternehmen, 
das viele Millionen US-Dollar umsetzte. Tate und Lashlee 
hatten vor der Gründung von Ashton-Tate bereits drei er- 
folgreiche Start-Up-Unternehmen gegründet, nämlich Dis- 
count Software, Software Distributors und Software Center 
International Discount Software war eines der ersten, die 
PC-Software direkt über den Postweg an den Endan- 
wender verkaufte. Software Center International war eine 
Einzelhandelskette für Software in den USA mit 
Geschäften in 32 Staaten. 


dBASE Il 

Mit dieser Erfahrung im Verkauf von Software stieg Ashton- 
Tate mit einer ungewöhnlichen Strategie in den Verkauf 
von dBASE Il ein. Die Käufer erhielten eine eingeschränkte 
Demoversion sowie die Vollversion auf einer separaten, 
versiegelten Diskette. Innerhalb von 30 Tagen konnten sie 
die ungeöffnete Diskette zurückgeben und erhielten den 
Kaufpreis zurück. Dies senkte die Hemmschwelle der 
Käufer, den doch stattlichen Betrag zu investieren und sor- 
gte für einen guten Absatz des Produkts. 

Im November 1983 ging Ashton-Tate an die Börse, was 14 
Millionen US-Dollar in die Kassen des mittlerweile auf 226 
Mitarbeiter angewachsenen Unternehmens spülte. Der Er- 
folg setzte sich fort: Am Ende des Geschäftsjahres hatten 
sich die Einnahmen auf 43 Mio. US-Dollar mehr als ver- 
doppelt, der Nettogewinn war von 1,1 auf 5,3 Mio. US-Dol- 
lar gestiegen. Das meiste Geld machte Ashton-Tate dabei 
mit dBASE Il und zusätzlich angebotenen Tools. 


War dBASE Il noch eine Assemblerentwicklung, 
schwenkten die Entwickler mit der Nachfolgeversion 
dBASE Ill Version 1.0 im Juli 1985 auf C als Programmi- 
ersprache um. Mit der Version 1.1 musste dann im 
November 1985 rasch ein Bugfix-Release hinterher 
geschoben werden. Die beste Stabilität wies dann die Ver- 
sion 1.2 auf, die Ashton-Tate als dBASE Ill Developer's 
Edition verkaufte. Bald danach folgte dBASE Ill+ (Version 
2.0) mit vielen Optimierungen. Ende 1987 verbuchte 
Ashton-Tate 318 Mio. US-Dollar. Der Erfolg zog natürlich 
auch Nachahmer und Dritthersteller an. Insbesondere 
Nantucket Software mit dem dBASE Compiler Clipper 
machte von sich reden. Clipper erlaubte es, eine dBASE 
Anwendung in ein selbstständig lauffähiges Programm zu 
übersetzen. Das Programm benötigte selbst dann keine 
dBASE-Software mehr. Das war ein großes Ding für die 
Anwender, aber ein Dorn im Auge von Ashton-Tate. Die ei- 
gene, 395 US-Dollar teure Runtime-Lizenz für den Einzel- 
platz zum Betrieb von dBASE Anwendungen wurde nicht 
mehr gebraucht. 


dBASE IV 

Mit dBASE IV konnte Ashton-Tate seine Erfolge allerdings 
nicht wiederholen. Das im Juli 1988 ausgelieferte Produkt 
sollte netzwerkfähig sein, SQL unterstützen und eine 
schnelle Anwendungsentwicklung erlauben. Aber die erste 
Version war instabil und fehlerbehaftet. Der mitgelieferte 
Compiler erzeugte keinen nativen Code für die Zielplatt- 
form, sondern nur einen Object Code, der die dBASE IV 
Laufzeitumgebung brauchte. Aber anstatt schnell ein Bug- 
fix Release nachzuschieben, konzentrierte sich Ashton- 
Tate auf andere Entwicklungen und vernachlässigte sein 
Flaggschiff. Als dann im Juli 1990 die Version 1.1 auf den 
Markt kam, hatte Ashton-Tate bereits deutlich Federn 
lassen müssen. Im August 1989 hatte das Unternehmen 
schon 400 seiner 1.800 Mitarbeiter entlassen müssen, der 
Marktanteil bei Datenbanken war auf 43% geschrumpft. 
Schließlich übernahm im Jahr 1991 dann Borland, was 


vom ursprünglichen Primus der Datenbanken übrig war. 


Weitere Software 

Ashton-Tate allein auf dBASE zu reduzieren, tut den 

Entwicklern aber unrecht. 

_____Schon 1983 kam mit Friday! eine dBASE-basierte 
Anwendung für die Kontakt- und Aufgabenverwal- 
tung auf den Markt. 


______Ashton-Tate vertrieb seit 1986 auch die Kalkula- 
tionssoftware Javelin auf dem internationalen Markt. 

___ Framework ist ein integriertes Programm mit einer 
Textverarbeitung, einer Tabellenkalkulation, Grafik- 
funktionen, einer Datenbank und einem Terminal- 
programm. Framework läuft unter MSDOS und 
bringt seine eigene GUI mit. 

______Multimate ist eine Textverarbeitung aus dem Jahr 
1985, die Funktionen ähnlich einer Wang Worksta- 
tion für Textverarbeitung auf den PC bringen sollte. 
Gegenüber dem Konkurrenten WordPerfect machte 
Multimate aber einen arg angestaubten Eindruck, 
der Markterfolg blieb aus. 

______Byline, ein von SkiSoft entwickeltes und ab 1987 
von Aston-Tate vertriebenes Desktop Publishing 
Programm, hatte durchaus begeisterte Anwender. 
Anders als andere DTP Programme besitzt aber 
Byline keine GUI, sondern verlangt eine genaue 
Beschreibung des Seitenlayouts. 
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Links 
https://en.wikipedia.org/wiki/Ashton-Tate 


Selbstbau 


Programmspeicher nicht nur für Commodore 64 


Die Universal 
Cartridge 


Typisch für einen Homecomputer der 1980er Jahre be- 
sitzt auch der Commodore 64 einen Steckplatz für Erwei- 
terungsmodule. Sie bringen Software auf den Brotkasten, 
ohne das hierfür ein teures Floppy Disk Laufwerk nötig 
wäre. Hier stellen wir ein Modul vor, das sich einfach selbst 


bauen und beladen lässt. 


ür den C64 gibt es eine große An- 

zahl an Modulerweiterungen. 

Grundsätzlich sind Software-Mo- 
dule von Hardware-Modulen zu unterschei- 
den. Software-Module bringen -- wie der 
Name es erwarten lässt -- neue Software 
auf den Rechner. Die Auswahl reicht von 
einfachen Spielmodulen bis zu komplexen 
Anwendungen. Hardware-Module enthal- 
ten hingegen Erweiterungen wie IEEE-488 
und RS-232-Schnittstellen, Hardware- 
Speeder oder neue CPUs. In diesem Arti- 
kel geht es um Software-Module und dar- 
um, wie sich eigene Software zusammen- 
stellen und auf ein Modul bringen lässt. 


C64 Module allgemein 


Software für den C64 gibt es bekannter- 
maßen entweder auf Compact Cassetten, 
Floppy Disks oder eben auf Modulen. Letz- 
tere zeichnen sich durch einfache Handha- 
bung aus: Einfach Modul in den C64 
stecken, einschalten fertig. Oberflächlich 
scheinen Software-Module identisch zu 
sein, doch ein genauer Blick offenbart Un- 
terschiede. Der Commodore 64 unterschei- 
det ursprünglich drei Modi, nämlich den 8K 
Modus, den 16K Modus und den 16K Ulti- 
Max Modus. Später wurde aus Gründen 
der Kapazitätssteigerung bei Modulen das 
sogenannte "Banking" eingeführt. Es um- 
geht die Größenbeschränkung von 16KB. 
Aber auch Module mit Banking sind zu je- 
dem Zeitpunkt auf 16K und die drei grund- 
sätzlichen Modi beschränkt. Nur sind hier 
die 16K Modulspeicher aus einem größe- 
ren Speicherbereich zu wählen. Der Ban- 
king Mechanismus ist aber nicht 
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standardisiert, weswegen Software auf 
dem Modul auf genau einen bestimmten 
Moduityp festgelegt ist. 


Die Universal Cartridge 


Praktisch sind sie also, die Module für 
den Commodore 64. Deshalb werden auch 
heute noch neue Programme für den Rech- 
ner als Module veröffentlicht, so zum Bei- 
spiel das beliebte Spiel "Sams Journey" 
von Protovision. Noch praktischer wäre es, 
würde es eine Möglichkeit geben, selbst 
nahezu beliebige Programme unkompli- 
ziert auf ein Modul zu bringen. Der Autor 
hat sich dieser Aufgabe angenommen und 
mit der Universal Cartridge eine solche 
Möglichkeit realisiert. 


64 oder 128K 
(zB. W27C512 oder 
W27C010) 


Vergleich der verschiedenen Universal Cartridge Modelle 


Die Universal Cartridge oder kurz "UC" 
ist ein Software-Modul für den C64, auf dem 
sich ein oder mehrere Programme und 
Spiele speichern und am C64 ausführen 
lassen. Das UC Modul hat einen eigenen 
Banking Mechanismus und kann alle drei 
Modul-Modi per Software emulieren. UC 
Module können folgende Programme star- 
ten: 

Software für 8K Module 
Software für 16K Module 
_____ Software für Ultimax Module 

Software, die als eine einzige Datei 
geladen und mit "RUN" gestartet 
werden (One-Filer) 

Software, die als eine einzige Datei 
geladen und mit RESET oder SYS 
gestartet werden 

Es gibt drei verschiedene Versionen der 
Universal Cartridge und alle drei sind für 
den Selbstbau gedacht. Dementsprechend 
wurde auf einen möglichst schlichtes und 
leicht nachzubauendes Design geachtet. 
Die Unterschiede in Bezug auf Bauteile und 
Bauweise sind in der Tabelle zusammen- 
gefasst. Genaue Anleitungen für den Auf- 
bau finden sich auf der Homepage des 
Autors. 


128, 256 oder 512K 
(zB. W27C010 oder 
W27E040) 


SRAM 32KB 


32KB 


TTL Bausteine) 741LS273 


2x 7415273 


Weitere Bauteile 4 Stück 
Kondensatoren 
(100nF) 


6 x Kondensatoren 
(100nF) 

1 Widerstand 

(10K Ohm) 


{ 


Ar 
5 
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Die fertigen Universal Cartridges 


uUC1 


Das kleinste UC Modul ist die UC1, das 
seit Mitte Juli 2021 verfügbar ist. Es unter- 
stützt ein EPROM mit einer Größe von 
64KB oder 128KB. Zusätzlich sind 32kByte 
SRAM vorhanden, mit dem die C64 Stan- 
dardmodule (8K, 16K, Ultimax) zu emulie- 
ren sind. Alle Bauteile sind in THT Technik 
aufgelötet, daher kann dieses Modul auch 
von einem unerfahrenen Bastler selbst her- 
gestellt werden. 


uUC2 


Das UC2 ist der große Bruder des UC1 
Moduls und wurde Anfang Oktober 2021 
veröffentlicht. Es unterstützt Flashspeicher 
bis zu 512KB (128K, 256K und 512K Flash 
Speicher). Das SRAM hat ebenfalls eine 
Größe von 512KB. Auch dieses Modul ver- 
zichtet des einfachen Nachbaus zuliebe auf 
SMD Bauteile. 


UC1.5 


Das UC1.5 ist ein Modul zwischen UC1 
und UC2. Es hat wie die UC2 zwei Regis- 
ter und kann daher ebenfalls 512 KByte 
große EPROM Speicher adressieren. Der 


Der UC-Builder 


Der UC-Builder kennt folgende Optionen: 


- 
- 
Byrazasugunuugem 


“ 
” 
» 
» 
” 
. 
’ 
r 
v 
v 
’ 
’ 
’ 
’ 
’ 
’ 


SRAM Speicher ist wie bei der UC1 32K 
groß. Die Bauteile sind in SMD Technik auf- 
gelötet, damit sie auf der kleinen Platine 
Platz finden. 


Beladen der Cartridges 


Um eine persönliche Programmsamm- 
lung für ein UC Modul zu erstellen, gibt es 
das Programm UC-Builder für den Win- 
dows-PC. Der UC-Builder nimmt die ge- 
wünschten C64 Programme und verpackt 
sie in eine einzelne Datei, die UC Image 
Datei. Diese Datei wird in den Speicher 
(EPROM, Flash) des UC Modul geschrie- 
ben. Damit steht die Programmsammlung 
dem C64 zur Verfügung. Die C64 Pro- 
grammsammlung auf dem UC Modul kann 
frei zusammengestellt werden, solange die 
Programme in eine der oben genannten 
Kategorien fallen. Die Größe der UC Image 
Datei darf den verfügbaren Platz im 
EPROM beziehungsweise dem FLASH 
Speicher natürlich nicht überschreiten. 
Wird ein W27C040 verwendet, darf die 
Image Datei eine maximale Größe von 
512KB haben. Die Größe setzt sich zusam- 


-h oder --help: Ausgabe aller verfügbaren Optionen zum UC-Builder. 


-V oder --version: Version des UC-Builder . 


-1 oder --UC1: Image Datei für ein UC1 Modul erstellen. 


-2 oder --UC2: Image Datei für ein UC2 Modul erstellen. Diese Image Dateien laufen auch in der UC1.5 

-5 oder --UC1.5: Image Datei für ein UC1.5 Modul zu erstellen. Diese Image Dateien laufen auch in der UC2 
-8 oder --MD: Image Datei für ein Magic-Desk Modul zu erstellen. Die maximale Größe ist MB. 

-9 oder --EF: Image Datei für ein EasyFlash Modul zu erstellen. 

-m oder --menu-csv: Angabe des Namens der zu benutzenden CSV Datei 

-i oder --image-file: Angabe des Namens der Ausgabedatei (UC Image Datei) 

-c oder --crt-file : Angabe des Namens der Ausgabedatei (CRT Datei). 


-v ; erhöht man die Anzahl der Meldungen, das UC-Builder wird gesprächiger. Die Option kann mehrfach verwendet 
werden. Ab drei -vvv erhält man detaillierte Informationen über den Aufbau der Image Datei, also die Adresse, Bank 
und Länge jedes Programmes in dem Image. Es wird auch angezeigt wie das Programm geladen und gestartet wird 


und ob das IO Register verborgen wird. 


men aus der Summe der einzelnen C64 
Programme plus der Größe des UC-Loa- 
ders. Der UC-Loader ist ein C64 Programm, 
das zur Bedienung des Moduls notwendig 
ist und das UC-Menü bereitstellt. 


Der UC-Builder 


Der UC-Builder ist nur erforderlich, wenn 
eigene Zusammenstellungen von Pro- 
grammen auf eine UC geladen werden sol- 
len. Fertige Imagedateien lassen sich mit 
einem EPROM Programmiergerät direkt 
aufbringen. 

Der UC-Builder erstellt eine UC Image 
Datei aus einem oder mehreren C64 Pro- 
grammen. Welche Programme das sind, 
beschreibt der Anwender in einer CSV Da- 
tei; deren Aufbau ist im Kasten am Ende 
des Artikels beschrieben. Die Image Datei 
enthält den UC-Loader, das UC-Menü für 
die Programmauswahl und optional einen 
File Browser (UC-FB) und natürlich alle 
ausgewählten C64 Programme. Der UC- 
Loader ist in dem UC-Builder bereits ent- 
halten und wird immer automatisch in die 
Imagedatei geschrieben, das UC-Menü 
wird vom UC-Builder jeweils passend er- 
zeugt. 

Um ein UC-Menü zu erstellen, braucht 
der UC-Builder folgende Informationen zu 
jedem C64 Programm: 


Name des Programms 
Art des Programms 
Dateinamen des Programms 


Der Name des Programms wird beim 
Start vom UC-Loader angezeigt. Die Art 
des Programms benötigt der UC-Loader, 
damit das Programm korrekt gestartet wer- 
den kann. Die Dateiname des Programms 
benötigt der UC-Builder, damit er es in die 
UC Image Datei integrieren kann. 

Der UC-Builder ist ein Programm für die 
Windows Kommandozeile. Es erstellt 
Image Dateien für das UC1, UC1.5 und das 
UC2 Modul. Wird es ohne Argumente auf- 
gerufen, dann sucht das UC-Builder nach 
einer CSV Datei namens menu.csv. Wenn 
beim Bau des UC-Image keine Fehler auf- 
treten, dann erfolgt nur die Ausgabe der 
Größe der Imagedatei sowie des freien 
Speicherplatzes. Die Berechnung des frei- 
en Speicher beruht auf der Annahme, dass 
ein 128K EPROM (W27C0O10) verwendet 
wird. Bei Verwendung eines 64K EPROM 
ist also darauf zu achten, dass die Image 
Größe 0x10000 nicht überschreitet. 

Am Ende wirft der UC-Builder zwei Da- 
teien aus: Die BIN Datei (EPROM Abbild) 
ist die UC Image Datei, die direkt in das 
EPROM für das Modul gebrannt werden 
kann. Die CRT Datei ist ein 8K CRT für den 
VICE, damit lässt sich das Menü im Emu- 
lator kontrollieren. Allerdings kann der VI- 
CE die Programme nicht richtig starten, da 
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der VICE die UC Hardware derzeit nicht 
emulieren kann. 

Die Image Dateien für Magic-Desk oder 
EasyFlash bestehen wie bei den UC- 
Images aus einer BIN Datei (EPROM Ab- 
bild) und einer CRT Datei für den VICE 
Emulator. Neuere Versionen des VICE 
Emulator können beide Arten (EasyFlash 
und Magic-Desk) perfekt emulieren. 


Der UC-Loader 


Nach dem Einschalten des C64 startet 
der UC-Loader. Der UC-Loader schaut 
nach, welche Programme auf dem Modul 
gespeichert sind. Ist es nur ein Programm, 
dann wird dieses direkt gestartet. Sind meh- 
rere Programme auf dem Modul, dann zeigt 
der UC-Loader die Namen aller Program- 
me im UC-Menü an. Der Benutzer vermag 
dann das gewünschte Programm auszu- 


wählen und der UC-Loader startet es. Mit 
den Tasten <F7> oder <F8> geschieht der 
Wechsel in den normalen C64 Eingabemo- 
dus (C64 BASIC). Die Taste <F7> schaltet 
dabei das UC Modul aus. Der Zugriff auf 
die UC-Register an der Adresse $DEOx 
funktioniert dann aber weiterhin. Mit der 
Taste <F8> werden zusätzlich auch die UC 
Register ausgeschaltet. Das Modul ist da- 
durch vollkommen unsichtbar und kann nur 
durch einen Modul Reset wieder aktiviert 
werden. 


Der UC File Browser 


Der UC File Browser wird vom UC-Me- 
nü mit der Taste <F1> gestartet. Der UC 
File Browser ist nur verfügbar, wenn im 
CSV File ein Dummy Eintrag gemacht wird. 
Der Menütext (erste Spalte) muss 'F1' lau- 
ten und die zweite Spalte enthält drei Bin- 


destriche ('---'). Die dritte Spalte wird nicht 
ausgewertet. Optional kann man statt des 
internen UC-FB auch einen eigenen Brow- 
ser einbinden, dazu muss nur die erste 
Spalte exakt'F1' enthalten. Der UC-FB läuft 
als 8KB ROM und ist ansonsten wie der 
normale FB v2 zu verwenden. Er startet 
Programme, wechselt in Verzeichnisse 
oder Diskimage-Dateien und verlässt die- 
se auch wieder. So ist eine sehr komforta- 
ble Navigation auf einem SD basierten 
Laufwerk (wie das SD2IEC) möglich. Der 
UC-FB kann auch CRT Dateien vom Typ O0 
starten. Es wird automatisch der Modul Typ 
(8K, 16K oder Ultimax) aus dem CRT File 
gelesen und entsprechend in den UC RAM 
geladen. Der Start erfolgt über einen Soft 
Reset. 


CSV Datei für den UC-Builder 


Der UC-Builder erwartet eine CSV Datei mit einer Beschreibung derjenigen Programme, 
aus denen die UC Image Datei gebaut werden soll. Die Datei kann aus mehreren Zeilen 
bestehen, jede Zeile muss in folgender Form aufgebaut sein: 


Programmname ; Programmtyp ; Dateiname ; Startoptionen 


Die ersten drei Felder sind verpflichtend, das vierte Feld ist optional und erst seit Version 
1.05 des UC-Builders vorhanden. 


Feld 1: Programmname 

Der Programmname wird nur für die Darstellung im UC-Menü benutzt. Sofern möglich, 
wird der Name automatisch in PETSCII konvertiert. Die Länge wird automatisch auf 17 
Zeichen reduziert, damit der Name am C64 problemlos darstellbar ist. 

Hierbei ist F1 ein reservierter Name. Der UC-Builder interpretiert diesen Eintrag als 
Aufforderung, einen File Browser einzubinden. Dieser erscheint nicht als Eintrag im UC 
Menü, sondern ganz unten links als Auswahl 'F1-File Browser‘. Mit der Taste 'F1' wird 
dieser dann gestartet, und zwar immer mit aktiviertem IO Register. So ist später eine 
Konfiguration des UC Modul möglich. Der File Browser kann entweder ein externes 
Programm oder der interne UC-File Browser sein. Soll dieser eingebunden werden, so 
muss als Programmtyp '---" angegeben werden, ein Dateiname ist nicht erforderlich. 


Feld 2: Programmtyp 

Der Programmtyp steuert, wie das Programm geladen wird und bestimmt die 

Konfiguration der UC Hardware vor dem Programmstart. Zudem wirkt sich der 

Programmtyp auf die Startoption aus, sofern diese nicht manuell in Feld 4 eingestellt wird. 

Folgende Kürzel sind in der Spalte Typ erlaubt: 

_____PRG: normales BASIC Programm, das an die Adresse $0801 geladen und mit 
RUN gestartet wird. 

____BIN: Ein Programm mit Ladeadresse, das an eine beliebige Adresse geladen und 
mit SYS oder RESET gestartet wird. 

_____BLKnnn und !nnn: Eine Datei OHNE Ladeadresse, die an eine beliebige 
Adresse geladen und mit SYS oder RESET gestartet wird. Es kann entweder 'BLK' 
oder '!' verwendet werden, das Ergebnis ist identisch. Die Datei wird an die 
angegebene Adresse 'nnn' geladen. Die Adresse kann dezimal, hexadezimal 
(beginnt mit '$' oder '0x') oder Oktal (beginnt mit '0') angegeben werden. 

______8KB: Das Programm wird als 8KB Modul gestartet. 

____16KB: Das Programm wird als 16KB Modul gestartet, 

____UltiMax: Das Programm wird als Ultimax Modul gestartet, 

_____CRT: Der Modultyp wird selbsttätig erkannt (nur bei CRT Dateien) 

"Sonderfall für die Verwendung des internen UC-FB, wenn der Programm 
Name exakt 'F1' ist 


Feld 3: Dateiname 

Dies ist der Name der einzubindenden Datei auf dem PC; er wird benötigt, damit der UC- 
Builder die Datei lesen und in die Image Datei einbinden kann. Es sind alle Arten von 
Pfaden erlaubt, die dem Betriebssystem bekannt sind, also Unterverzeichnisse, andere 
Laufwerke, absolute Pfade, Netzlaufwerke und so weiter. Dateien werden normalerweise 


72 


einfach als Byte Stream gesehen. Es gibt aber Ausnahmen, die inhaltlich interpretiert 

werden, nämlich die reservierten Namen POO und CRT: 

_____P00: Diese Dateien werden besonders behandelt, der POO Header wird überlesen 
und ab Byte [0x1A] als Inhalt verwendet 

_____CRT: Diese Dateien sind 'Modul Dateien' für den Emulator. Sofern es CRT Dateien 
vom Typ 0 (8K, 16K, Ultimax) sind, werden sie vom UC Builder und vom UC File 
Browser richtig interpretiert. 


Feld 4: Startoptionen 

Dieses Feld ist optional und dient dazu, bei Bedarf eine bestimmte Startoption zu 
erzwingen. Ohne eine Angabe in diesem Feld startet der UC-Loader alle PRG-Dateien 
mit einem 'RUN' Befehl und alle Moduldateien mit einem Soft-RESET. Bei allen springt 
das Modul nach dem LOAD ins BASIC. Ist eine Startoption definiert, so führt der UC- 
Loader diese nach dem LOAD aus, und zwar unabhängig davon, ob sie einen Sinn ergibt 
oder nicht. 

Folgende Startoptionen sind erlaubt: 


RESET: Nach dem Laden des Programmes wird ein Soft RESET ausgeführt. Das 
ist die Vorgabe bei Programmen des Typs 8KB, 16KB, UltiMax und CRT. 


_____SYSnnn: Nach dem Laden des Programmes wird ein SYS auf die Adresse 'nnn' 
ausgeführt. Die Startadresse kann dezimal, hexadezimal (beginnt mit '$' oder '0x') 
oder Oktal (beginnt mit '0') angegeben werden. 

_____RUN: Nach dem Laden des Programmes wird ein RUN ausgeführt. Sofern es sich 
bei dem Programm um ein BASIC Programm handelt, wird es automatisch nach 
dem LOAD ausgeführt. Das ist die Vorgabe bei Programmen des Typs PRG. 

_____ READY: Nach dem Laden des Programmes springt der UC-Loader direkt nach 
dem LOAD in den Direktmodus des BASIC (Interpreter Loop). Das ist die Vorgabe 
bei Programmen des Typs BIN und BLK. 


_____ ROM: Das Programm wird direkt im ROM (EPROM/FLASH) der Universal 
Cartridge ausgeführt, ohne zuerst ins RAM geladen zu werden. Bei der Startoption 
ROM selektiert der RESET: Nach dem Laden des Programmes wird ein Soft 
RESET ausgeführt. Das ist die Vorgabe bei Programmen des Typs 8KB, 16KB, 
UltiMax und CRT. 


Bei der Startoption ROM UC Loader selektiert die richtige Speicherbank und startet dann 
per Reset. Module vom Typ 8K und 16K werden direkt an der unteren Grenze einer 16K 
Bank angeordnet. Ultimax Module mit 8K werden automatisch in dem oberen 8K Block 
einer Bank angeordnet, das ist Standard für Ultimax Module wegen dem Reset Vektor. 
Diese Methode hat den Nachteil, dass ein Programm genau an den Blockgrenzen einer 
Bank angeordnet werden muss. Dadurch entstehen unter Umständen Lücken zum vorher 
geladenen Programm, der Speicher kann nicht mehr vollständig benutzt werden. Aber 
diese Option eignet sich gut, wenn hauptsächlich Modulprogramme (CRT Dateien) mit 
8K und 16K Größe benutzt werden, beispielsweise das Multi-MAX Modul. Bei vielen 8K 
Modulen wird der Speicher ideal genutzt, wenn sich eine 8K und eine Ultimax immer 
abwechseln. 


Universal Lartridge 


Hello MKorid 
Charset Editor 
Lange Schlange 
Labyrinth 

Frosch 

Fort flpocalypse 
Jupiter Lander U2 
Help! 

ExBasic-II 

Exfiss 


Dead Test 


Ultı RAM Test 


[Fr t » Fnche »Tmete dur Aueh „GEST he eler ba aa De Tao oe 


Fi-File Browser 


Commodore MaxMachine 


Die UC Module sind dafür konzipiert, in 
einem C64 Computer zu arbeiten. Neuere 
UC Module können aber auch in einer Com- 
modore MAX Machine laufen. Die Module 
UC-1 und UC-1.5 haben dazu einen optio- 
nalen Jumper, mit dem sie in den MAX Ma- 
chine Modus geschaltet werden können. 
Das UC-2 Modul kann per Software Ein- 
stellung in den MAX Machine Modus wech- 
seln. Ein UC Modul im Max Machine Modus 
läuft auch in einem C64. 

Der MAX Machine Modus unterliegt den 
Beschränkungen dieser Zielplattform: 


es funktioniert nur noch der Ultimax 
Modus 

der UC Loader funktioniert in die- 
sem Modus nicht 

ein C64 hat nur noch AK RAM 


CE EC Ga I 


<UL1) 


F7-BASIEC FS-Kill 


an einer MAX Machine sind 2K 
RAM (intern) und 2K extern (UC- 
RAM) von $0800 bis $OxOFFF 
das Signal IO-1 ist direkt mit /EX- 
RAM verbunden 
das Signal IO-2 ist direkt mit /EX- 
ROM verbunden 
die UC Register sind in einer MAX 
Machine in dem 2K Adressraum 
$0800-$0FFF ansprechbar (statt 
wie gewohnt ab $DExx) 

an einem C64 hat man 256 Byte UC 
RAM im IO-2 Bereich ($DFxx) 

Da der UC Loader im Max Machine Mo- 
dus nicht funktioniert, sind auch UC Images 
nicht mehr nutzbar. Es braucht eine Soft- 
ware, die speziell für diesen Modus entwi- 
ckelt wurde. Dies ist zum Beispiel die 
MultiMax Software für das UC Modul. 


UNE wann se rt Sie sich-hin und 
schreiben für die. LOAD? 
E E Machen Sie mit und werden Sie Autor für das Retrocomputer- 


“. Magazin aus dem Verein zum Erhalt klassischer Computer e.V. 


Spiele und... 
1 meisten interessiert. 


Wir suche ständig interessante Themen rund um klassische Com- 
_L_ puter, Homecomputer, Minicomputer, Progammierung, klassische 
natürlich über das Thema, das sie gerade am aller- 


Fazit 


Wer nun Lust bekommen hat, sich selbst 
an den Bau einer Universal Cartridge zu 
wagen, dem seien die ausführlichen Anlei- 
tungen auf der Homepage des Autors ans 
Herz gelegt. Viel Spaß mit dem Nachbau 
und der Verwendung der Universal Cart- 
ridge. 


Links 


https:/oe’7twj.at/index.php? 
title=Universal_Cartridge 
https://oe’7twj.at/index.php? 
title=Universal_Cartridge_1 
https://oe’7twj.at/index.php? 
title=Universal_Cartridge_2 
https://oe’7twj.at/index.php? 
title=Universal_Cartridge_1.5 
http://www.harries.dk/files/ a 
C64MemoryMaps.pdf 


Ueber den Autor 


Thomas Winkler ist Ingenieur 
und beschaeftigt sich in 
seiner Freizeit mit dem 6502, 
Mikrocontrollern, CPLD und 
FPGA. Er lebt in Oberhofen im 
oesterreichischen Inntal. 


Melden Sie sich noch heute bei uns: 
redaktion@load-magazin.de 
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Selbstbau 


Mit dem Raspberry PI-Zero 


Commodore 1541 
Laufwerk emulieren 


Das Commodore 1541 Laufwerk ist selbst ein Computer. 
Er besteht aus einer CPU, ROM, RAM, l/O-Geräten und 
der Laufwerksmechanik. Es existieren einige Projekte, 
die dieses Gerät durch moderne Hardware emulieren und 
anstelle von Disketten auf SD Karten und Floppy Images 
1 setzen. Ein kostengünstiges Gerät zum Selbstbau stellt 


dieser Artikel vor. 


ie Idee, mit einem Raspberry Pi 

eine Laufwerks-Emulation für 

den Commodore 64 und 128 zu 
bauen, ist nichts neues mehr, Das wurde 
bereits von Steve White vor einigen Jah- 
ren mit dem Pi1541 verwirklicht. Im Gegen- 
satz zum SD2IEC emuliert der Pi1541 
einen 6502 und die beiden 6522er. Da der 
Pi1541 Code auf seinem emulierten 6502- 
Kern ausführt, unterstützt er eine große An- 
zahl von Schnellladern (Spiele und Demo- 
szenen), sogar kopiergeschützte Originale. 
Ursprünglich diente ein Raspberry Pi3 (Mo- 
dell 3B, 3B+ oder 3A+) als Steuer-Rech- 


ner. Dessen ARM-Prozessor enthält meh- 
rere Kerne und so vermag etliches gleich- 
zeitig intern abzulaufen. 


Pi Zero als Basis 


Allerdings sind diese Mini-Computer im 
Vergleich zu anderen Lösungen nicht bil- 
lig. Daher kam schon früh der Wunsch auf, 
ob das ganze nicht vielleicht auch mit ei- 
nem sehr viel günstiger zu beschaffendem 
Pi Zero zu realisieren wäre. Steve White 
setzte sich also daran, den Kernal seiner 
Emulation umzuschreiben, damit auch ein 
Pi Zero mit nur einem Kern so eine Aufga- 


Pi1541 Interface Wiring Diagram 


Raspberry Pi 3 
GPIO Header 


be übernehmen kann. Zwar sind mit dem 
Pi Zero als Steuer-Rechner gewisse Abstri- 
che nötig. Zum einen gibt es keine Bild- 
schirm-Ausgabe auf HDMI wie bei Pi 3. 
Zum anderen wurde anfangs auch kein Pi- 
ezo-Speaker unterstützt wie bei den "gro- 
ßen Brüdern". Dort dient dieser dazu, Lauf- 
werksgeräusche nachzuahmen und damit 
die Emulation retromäßiger wirken zu las- 
sen. Aber all das ist zu verschmerzen, wenn 
man den wesentlich günstigeren Preis zu 
Grunde legt, denn der Pi Zero kostet gera- 
de mal ein Fünftel eines Pi 3. 

Am Anfang gab es noch große Proble- 
me mit dem Timing. Vor allem Programme, 
die sich auf mehrere Dateien aufteilen wur- 
den eher schlecht unterstützt. Inzwischen 
funktioniert das alles mit der aktuellen Soft- 
wareversion 1.24 schon wesentlich besser, 
auch der Piezo Speaker tut es jetzt. 

Das Grundprinzip der Schaltung hat sich 
hingegen kaum verändert. Für die neues- 
te Platine wurde lediglich der unzuverläs- 
sigere und immer wieder für Probleme 
sorgende Level-Shifter (das kleine Platin- 
chen mit den vielen Transistoren) gegen 
einen recht simplen 7406 (Hex-Inverter- 


| Browsing Mode 


swi | Select /Start Emulation Exit Emulation 


sw2 | Move up Previous Disk 


SW3 | Move Down Next Disk 


sw4 | Exit Folder nfa 


Fin Name Name Pit se [re 
01 3.3V DC ®® 5VDC_02 
03 (e)(e) 5vDc 04 Commodore 64 
05 0,09 GND 06 6 PIN SERIAL PORT 
07 IN_SW4 @le) 
09 GND (@e) 1 SRQIN 
11 OUT_CIK OIC OUT DATA 12 2 GND 
13 IN_Sw1 OO: _isw3 GND 14 3 ATN OUT 
15 IN_SW2 @® 0 IN_Sw3 16 4  CLK IN/OUT 
17 3.3V DC (*)®) IN_ATN 18 5 DATA IN/OUT 
21 OO = 
23 (e)(e) 
25 GND (e)(e) 
27 (e)(e) 
29 IN_SWw5 @e) GND 
31 OUT_RESET (ee) u OUT_ATN 
33 OUT_SOUND @le) (di) GND 34 4Ch Bi-Dir Level Convert; Sparkfun BOB-12009 or similar 
35 OUT_SRQ (e)(@ OUT_LED 36 7406 Hex Inverter Buffer | Date | mo — | 
37 IN_CLK We | _ınreser 38 | 100 nF Ceramic a 
39 GND (e)(e) Standard LED, If 20 mA typical Stephen white 


IN_SRQ 40 


Designed By 


100 ohms (or higher to decrease D1 brightness) 


Drawn By | Todd Trann 


Piezo buzzer, HPM14AX or similar 


Copyright (c) 2018 Stephen White 
CC-BY-SA 4.0 


Momentary contact, normally open switches 


Bild von Thorsten Kuphaldt http://cbmmuseum.kuto.de/floppy_vc1541.html 


Die fertig aufgebaute Platine 


Buffer) getauscht. Das erzeugt noch etwas 
mehr Stabilität. 


Optimiertes Layout 


Die Platine wurde wieder einmal von Mat- 
thias Lorenz gezeichnet, jedoch nach Vor- 
gaben des Autors. Diese waren vorher mit 
einem kleinen Team in seinem damaligen 
Forum Loop64 besprochen worden. Ziel 
dabei war es, ein einfaches Design zu 
schaffen, das auch individuell anpassbar 
ist. So gibt es sowohl die Möglichkeit, das 
Laufwerk mittels 5 Tastern zu steuern, oder 
aber auch mit nur 2 Tastern und einem Ro- 
tary-Device (Drehgeber). Dieser übernimmt 
die Funktion der Taster (Up, Down und Se- 
lect) und erlaubt es so, bequem durch das 
Menü zu steuern. Ein Druck auf die Achse 
wählt eine Datei aus und mounted sie di- 
rekt. Diese Datei liegt meist im Format *.d64 
vor und wird dann wie eine echte 1541-Dis- 
kette behandelt. Sie kann ganz normal mit- 
tels LOAD "$",8 gefolgt von LIST einge- 
lesen und dargestellt werden. 


Verbesserungen 


Zusätzlich ist es möglich, sowohl ein 
OLED-Display mit 128x32 Pixeln oder 128x 
64 Pixel anzuschließen und somit entwe- 
der 2 oder 4 Zeilen des Inhaltsverzeichnis- 


Das Layout der Platine 


ses darzustellen. Im Options.txt auf der 
SD-Karte wird definiert, welches Display 
vorhanden ist. Weiterhin wurde durch eine 
einfache Pinreihe die Möglichkeit geschaf- 
fen, ein Kabel direkt an die Platine anzulö- 
ten oder auch mittels Pin-Header zu 
stecken. Dies spart sowohl eine zusätzli- 
che IEC-Buchse (DIN- 6H), als auch die 
lästige Suche nach einem IEC-Kabel. Ist 
das Kabel bereits fest mit der Platine ver- 
bunden, kann es der Nutzer auch nicht ver- 
gessen, transportiert er sein Gerät. Die 
Platine erhält ihren Strom ganz normal wie- 
der über einen Hohlstecker, der am besten 
von einem USB-Netzteil oder -Port aus ge- 
speist wird. Ist das Netzteil des C64 stark 
genug, so lässt sich das Laufwerk auch di- 
rekt von dort aus versorgen. 


Gehäuse 


Wer ein Pi Zero 1541 Laufwerk nachge- 
baut hat, braucht auch ein passendes Ge- 
häuse. Hier hat der User "bernd-7" im 
Forum.Classic-Computing.DE einen Ent- 
wurf für ein Gehäuse aus dem 3D-Drucker 
vorgestellt und feilt gegenwärtig noch an 
Details. Wer einen passenden Drucker 
besitzt, kann also selbst ein Gehäuse 
herstellen. 


® 08! 


POWER SWITCH 


PI ZERO 


Fazit 


Alles in allem ist das Pi Zero 1541 Lauf- 
werk ein sehr günstiges Gerät, das im 
Selbstbau mit etwa 30€ an Materialkosten 
zu Buche schlägt. Es kommt schon ziem- 
lich nahe an vergleichbare Emulationen 
heran. Noch geht nicht alles damit, aber 
die Software wird stetig verbessert. Es lohnt 
sich also, die Schaltung nachzubauen und 
dem Pi Zero eine Aufgabe am Commodo- 
re 64 zu geben. 


Links 


Pi1541 Homepage 
https://cbm-pi1541.firebaseapp.com 
Forums-Thread zum Bau des Pi Zero 1541: 
https://forum.classic-computing.de/ 
forum/index.php ?thread/23234-neues- 
pi1541-zero-platinen-layout-von-matthias- 
ausm-f64-kompakt/ 


Ss Die erforderlichen 
, Dateien zum Selbstbau 
finden sich auf der Heft-CD 


Ueber den Autor 


Andreas Schabesberger 
bastelt gern an Retro- 
Rechnern herum, musste in 


seiner Jugend aber ohne C64 
auskommen. Das holt er jetzt 
mit wachsender Begeisterung 
nach. 


Selbstbau 


Kopieren hartsektorierter Disketten 


Das Fluxcopy Projekt 


Auf dem originalen IBM PC, aber auch auf vielen ande- 
ren klassischen Computern kommen softsektorierte 5 1/4 
Zoll Disketten zum Einsatz. Um diese heutzutage auszu- 
lesen und die Inhalte zu archivieren, existieren Lösungen 
wie Kryoflux. Leider versagen diese, geht es um hartsek- 
torierte Disketten. Dafür braucht es eine Speziallösung, 
bestehend aus einer Hardware am USB Port und pas- 


sender Software. 


vertierung von CP/M und UCSD Dis- 

ketten-Images hat der Autor eine 
Menge Know How gesammelt (siehe LOAD 
Ausgabe 6, Seite). Für das Erstellen und 
Zurückschreiben der Images wird dabei 
SAMdisk (Tool von Simon Owen) am PC 
verwendet. Das hat jedoch seine Grenzen: 
Am PC können nur Disketten gelesen oder 
geschrieben werden, für die der Disketten- 
controller ausgelegt ist. Das ist meist ein 
WPD765 oder ein ähnliches Produkt. Der 
verarbeitet aber nur soft-sektorierte Disket- 
ten im FM- oder MFM-Format. Andere For- 
mate sind nicht lesbar, da der Controller 
dies ablehnt. Das gilt auch für hartsektorier- 
te Disketten, die anstelle eines einzelnen 
Indexlochs beispielsweise 17 Indexlöcher 
besitzen und so die Lage der Sektoren je 
Spur fest vorgeben. 


| m Zuge seiner Arbeiten für die Kon- 
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Projektziele 


Getrieben durch die Erfahrungen mit den 
Disketten einer AES-Lanier Textverarbei- 
tungsmaschine entstand daher ein Projekt, 
das zum Ziel hat, diese Lücke zu schlie- 
ßen. Projektziel war es, eine Lösung zum 
Einlesen von hartsektorierten Disketten via 
USB-Schnittstelle am Windows-PC zu ent- 
wickeln. Hierzu sollten das Programm 
"FLUXCOPY" und die Zusatzhardware 
"FLUXTEEN" neu entwickelt werden. Die 
Images der einzelnen Tracks sollen sich 
als FLX-Dateien (eigenes Format für FLUX- 
COPY) am PC speichern lassen. Ebenso 
sollte es möglich sein, diese Images spä- 
ter auf andere, unformatierte Disketten glei- 
chen Formats - also mit gleicher Anzahl an 
Sektoren — trackweise zurückzuschreiben. 
Als Ziellaufwerk sollte dabei dasselbe Lauf- 
werk wie beim Einlesen verwendbar sein, 
aber auch ein anderes Laufwerk. Insofern 
sollten Unterschiede bei den Drehzahlen 


berücksichtigt werden. Als Schnittstelle zu 
den Diskettenlaufwerken wurde ein Shu- 
gart Bus (Drive Interface created by Shu- 
gart Associates) für ein 34-poliges Flach- 
kabel vorgesehen. Für 8 Zoll Disketten ist 
dann ein 34-zu-50 Pin-Adapter erforderlich. 


Überlegungen zu FLUXTEEN 


Um ein Floppylaufwerk via USB steuern 
zu können, braucht es einen Prozessor. Die 
reinen Steuersignale wie Motor On, Step 
Impulse, Read Only und andere ließen sich 
ohne weiteres mit einem Arduino UNO be- 
werkstelligen. Dieser kann auch den An- 
schluss per USB meistern. Anders sieht es 
mit den Schreib- und Lesedaten aus. Die 
Fluxwechsel benötigen eine wesentlich hö- 
here Datenrate als ein Arduino UNO mit 
seinem Takt von 16 MHz zu leisten in der 
Lage wäre. Der bereits erwähnte KryoFlux 
arbeitet mit einer Samplingrate von rund 
24MHZz, andere Systeme zumindest mit 16 
MHZ. Aus diesem und anderen Gründen 
entschied sich das Projekt für einen TEEN- 
SY 4.1. Die CPU des TEENSY arbeitet mit 
600MHZz und verfügt auch über ein super- 
schnelles, 512 KByte großes RAM. Damit 
lässt sich eine Samplingrate von 25MHz 
leicht erreichen. 

Da der TEENSY 4.1 jede Menge an Ti- 
mern, Countern und anderem enthält, sind 
außer den Levelshiftern (TEENSY verträgt 
nur 3,3 Volt) keine ICs nötig. Er erfordert 
lediglich einige Widerstände, Leuchtdi- 
oden, ein paar Kondensatoren, sowie den 
34-poligen Anschlussstecker für das Flach- 
kabel zum Floppylaufwerk. Die Stromver- 
sorgung von FLUXTEEN erfolgt aus- 
schließlich über den Micro-USB Anschluss 
(SVolt/max. 500mA,). Der erste Testaufbau 
von FLUXTEEN erfolgte auf einem Steck- 
board. In der derzeitigen Print-Version der 
Platine ist zusätzlich zum 34-poligen Flach- 
kabelanschluss noch ein 34-poliger Edge- 
Connector vorgesehen. Ein solcher Con- 
nector wird auch an 5,25 Zoll Laufwerken 
verwendet, zum Beispiel den externen 
Laufwerken des Philips P2500 Rechners. 
Die Anschlüsse sind wahlweise zu verwen- 
den. 


Batterie dzt. 
nicht benutzt 


Micro SD dzt. || 34 poliger Flachkabel- 
nicht benutzt Anschluss 
R 0.03 
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Die fertig aufgebaute FLUXTEEN Platine und ihr Layout 


Die Firmware programmieren 


Der TEENSY ist in C++ mittels der Teen- 
syduino IDE programmierbar. Diese ist gra- 
tis im Netz verfügbar und auch relativ 
einfach zu bedienen. Auf Windows XP kann 
als letzte für dieses Betriebssystem er- 
schienene Version das Release 1.8.5 in- 
stalliert werden. Für Windows 10 gibt auch 
neuere Versionen, der Autor nutzt derzeit 
die Version 1.8.13. Abgesehen von kleinen 
Unterschieden im Handling sind beide Ver- 
sionen identisch benutzbar. Um auch 
TEENSY-Modelle programmieren zu kön- 
nen, bedarf es noch der Zusatzsoftware 
Teensyduinoinstall.exe, die es ebenfalls 
gratis im Netz gibt. Sie wird auf die Ardui- 
no-IDE aufgespielt und ab diesem Zeit- 
punkt sind auch sämtliche TEENSY- Mo- 
delle in der IDE verfügbar, inklusive diverser 
Beispielprogramme. 

Aufgrund der wesentlich schnelleren 
CPU mit 600Mhz braucht es praktisch kei- 


sw. FLUXCOPY Test Vers. 0.90 by PAW 


Track from: to: rs 


Select Panel 


Wiite € 


nen Assemblercode, die Programmierung 
kann vollständig in C++ erfolgen. Die Leis- 
tung entspricht zwischen 600 bis 1000 
MIPS, weil ein oder zwei Befehle pro Takt 
ausgeführt werden können. 

Ist die Firmware erst einmal erstellt, muss 
sie noch auf den TEENSY kommen. Dazu 
muss das TEENSY Ladeprogramm gestar- 
tet werden, es findet sich üblicherweise un- 
ter \hardwareltools\teensy.exe, wenn Teen- 
syduino IDE installiert ist 


Die PC-Software FLUXCOPY 


Um FLUXTEEN benutzen und steuern 
zu können, braucht es eine passende Soft- 
ware auf dem PC. Auch diese entstand im 
Projekt, und zwar als GUI Anwendung für 
Windows. Hier sind in einer Eingabemas- 
ke diverse Parameter einzustellen, bevor 
sich ein Image einer Diskette erstellen 
lässt. Ein Großteil davon sind auch über 
die Kommandozeile zu initialisieren. Im 
Feld "Port COM" muss die entsprechende 


EIER) =. FLUXCOPY Test 


Port COM ß 
Drive select — —— —— 
IC HOL TIC HET 


Drive density 40/80 track - 
48tpi 


© götpi 


17 12 @ 20 


Side Use single/double step — 
[Fsingie @ double € | 


34 poliger Edge 
Connector 


Schnittstelle angegeben werden. Es kann 
aus bis zu vier Drives ausgewählt werden. 
Je nach Laufwerkstyp (48tpi oder 96tpi) 
und Datenträgerbeschaffenheit muss eine 
Auswahl in den Feldern "Drive density" und 
"Use single/double step" getroffen werden. 
Wichtig ist die Angabe der Anzahl von Ko- 
pien (Num of Retries): Bei 0 wird jeder Track 
nur einmal eingelesen. Das ist natürlich am 
Schnellsten und braucht auch den gerings- 
ten Platz. Da aber die Richtigkeit der Da- 
ten während der Aufzeichnung nicht über- 
prüft werden kann, ist es empfehlenswert, 
mehrere Durchgänge aufzuzeichnen (Vor- 
gabewert ist 2). Damit das Ergebnis auch 
überprüft werden kann, gibt es das Tool 
FLUXDUMP. Damit lassen sich die Check- 
summen aller Sektoren für ein bestimmtes 
Format überprüfen. 

Das Verzeichnis für die FLX-Dateien 
muss immer ein direktes Unterverzeichnis 
zum Verzeichnis von FLUXCOPY.exe sein. 
Das Image einer Diskette besteht aus je ei- 
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Drive density 40/80 track 
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Select Panel 
Read 
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Folder for Fluxfiles: 


Exit 
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FLUXCOPY Eingabemaske für das Lesen von Disketten 


Num of Retries 
or ıC 2@ 3C al 5 
[FLux1 


<<<Drive3>>> DiskSize = 5.25" MaxTrack = 79 Sides = 2 
PHILIPS Dens: DD Timings[msec): 500,1,10,6,20 


Folder for Flusfiles: 


Image to use for write 
VCH FITCHIT EST 56. 


[FLux1 


ä <<<Drive3>>> DiskSize = 5.25" MaxTrack = 79 Sides = 2 
Exit 


PHILIPS Dens: DD Timings{msec): 500,1.10,6,20 


..und die Ansicht für das Zurückschreiben. 
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Selbstbau 


Bytes untergebracht werden, also 5 


08 ECK FOR! Track:01 Sec:03 (0) 

05 20 2D 20 5A 65 69 6C 65 3A 20 32 0D EL ED 09 Ai ea rgrarge 1/3 Bits pro Zeichen. Die Verzeich- 
E9 44 61 73 20 69 73 74 20 76 69 65 6C 20 54 65 .Das ist viel Te niswerte berechnen sich dabei als 
TED OA IE OD=EL-ED xt—— Zeiler I Doppelbytewert = (1. Zeichen * 
09 E9 44 61 73 20 69 73 74 20 76 69 65 6C 20 54 ..Das ist viel T 1600) + (2. Zeichen * 40) + (3. Zei- 
65er 2er ext - Zeile: 4.. chen). Wer sich für die Details die- 
ED 09 E9 44 61 73 20 69 73 74 20 76 69 65 6C 20 ...Das ist viel =es Fonmalsiintere eier ee taufden 
54..65..78-174..20..2D-20-5A..65-.69.6C..65.-3A20..35..0D Text - Zeile: 5. Thread "XY - Software Rätsel un- 
El ED 09 E9 44 61 73 20 69 73 74 20 76 69 65 6cC ....Das ist viel Se . 

20.54 65.3 74 20 20 20.52 65 69 60.65.32 20 36 Text. - Zeile: 6 gelöst" im Forum.Classic-Compu- 
0D El ED 09 E9 44 61 DE 00 00 00 00 00 000000 I..... Dane ting.DE verwiesen (siehe Links). 


Beispiel für einen eingelesenen Sektor 


ner FLX-Datei pro Spur und Seite, also üb- 
licherweise aus 40, 80 oder 160 Dateien. 
Das Anklicken von "Select Panel Write" 
innerhalb von FLUXCOPY zeigt ein leicht 
geändertes Formular, in dem sich auswäh- 
len lässt, welche der zuvor gespeicherten 
Kopien zurückgeschrieben werden sollen. 
Zum Redaktionsschluss waren bereits neu- 
ere Versionen in Arbeit. Diese werden ein 
ähnliches Layout haben und auch eine 
Möglichkeit zum Lesen und Schreiben von 
C64- Disketten und anderen anbieten. 


Erfolgreiche Tests 


Mit dem Testaufbau und lauffähigen Ver- 
sionen von FLUXCOPY ging es anschlie- 
ßend daran, Disketten von einer AES- 
Lanier Textverarbeitungsmaschine auszu- 
lesen. Dies klappte mit dem angeschlos- 
senen Laufwerk nach ein paar Anläufen 


ohne Probleme. Spannend wurde es beim 
Zurückschreiben. FLUXCOPY meldete kei- 
ne Fehler und die Textverarbeitungsma- 
schine akzeptierte die Diskette tatsächlich. 
Damit war das gesteckte Ziel erreicht, näm- 
lich die hartsektorierten Disketten von AES- 
Lanier kopieren zu können. 

Im Zuge der Analysen der AES Disket- 
ten fanden sich viele interessante Beson- 
derheiten: 


Im AES 7100 werden doppelseitige 
80 Track Laufwerke verbaut, aller- 
dings wird nur jede zweite Spur auf 
der ersten Seite auch tatsächlich 
genutzt. Die Disketten sind also nur 
einseitig mit 37 Tracks in doppeltem 
Abstand beschrieben. 

Das logische Diskettenformat ver- 
wendet ein komprimiertes Inhalts- 
verzeichnis, bei dem 3 Zeichen in 2 


Zukunftsaussichten 


Da in diesem Projekt noch jede Menge 
Potential steckt, geht die Entwicklung na- 
türlich weiter. Das Programm FLUXKRYO- 
CONV kann RAW-Dateien, die mit KryoFlux 
erstellt wurden, in FLX-Dateien für FLUX- 
COPY umwandeln. Die Fluxdaten müssen 
dafür je Track und Seite in einer eigenen 
Datei gespeichert sein. So konvertierte 
Images kann FLUXCOPY dann wieder auf 
Disketten schreiben. 

Die am 22. August 2021 veröffentlichte 
Version 050 von FLUXDUMP bietet nun 
auch die Möglichkeit, viele andere Forma- 
te zu dumpen: 


FM und MFM-DD-Disketten (Soft- 
sektor, UPD765-kompatibel) 
MFM-HD-Disketten (Softsektor, 
„PD765-kompatibel) 
WANG-FM-Disketten (Hartsektor) 
C64-Disketten (GCR Softsektor) 


Die Entstehung 
des Projekts 


Natürlich gibt es diverse Tools wie KryoFlux 
und andere, mit denen auch andere Form- 
ate gelesen und geschrieben werden 
können. 2020 klagte mir Günther Pospis- 
chil sein Leid, dass er für seine AES-Lani- 
er Textverarbeitungsmaschine keine neuen 
Disketten erstellen kann, da es kein Kopi- 
er- und Formatierungsprogramm dafür gibt. 
Es handelt sich dabei um 5.25 Zoll hartsek- 
torierte Disketten mit 16 FM-formatierten 
Sektoren, es gibt also 17 Indexlöcher in der 
Diskette. Bei einem Versuch in meinem PC 
wurde die Diskette nicht einmal erkannt. 
Viele PC Laufwerke können mit so kurzen 
Intervallen beim Index nichts anfangen, sie 
interpretierten das als "keine Diskette im 
Laufwerk". 


Günther konnte mit KryoFlux wohl Images 
aufzeichnen, aber beim Rückschreiben auf 
Diskette gab es Probleme. Laut KryoFlux 
Doku ist nur das Lesen möglich, nicht aber 
das Schreiben. Günther konnte KryoFlux 
mit einem Trick überlisten, indem er 16 In- 
dexlöcher abdeckte und damit eine Soft- 
sektor-Disk vortäuschte. Allerdings gab es 
dann beim Einlesen auf dem Originalsys- 
tem (nachdem wieder alle Löcher 
freigemacht wurden) jede Menge Lese- 


fehler, die wohl auf die Drehzahlschwan- 
kungen der Laufwerke zurückzuführen 
sind. Vermutlich verwendet dieses System 
keine PLL (phased locked loop) um die 
Schwankungen auszugleichen, sondern 
liest mit fikem Timing die Daten ein. Damit 
ist dieser Weg nicht gangbar. Dieses Prob- 
lem wurde schon an anderer Stelle disku- 
tiert: 

"Ich habe ein AES 7100 samt Typenrad- 
Drucker und Beschreibung der Software 
(Textverarbeitung AES Office System 
4.40.22). Angeblich soll es auch CP/M 
geben, das habe ich aber nicht. Die beiden 
Systemdisketten mussten ursprünglich 
teuer gekauft werden und es gibt dafür kein 
Kopierprogramm am AES selbst. Ich woll- 
te sie auch schon länger irgendwie sichern 
bzw. kopieren. Mit KryoFlux scheint die 
Sicherung funktioniert zu haben, nur bringe 
ich das Image eben nicht mehr zurück auf 
Disketten (leere hartsektorierte Disks habe 
ich zur Verfügung). Wenn ich etwas Zeit 
habe, werde ich mit den KryoFlux Her- 
stellern Kontakt aufnehmen und die Disk- 
Images übermitteln. Dazu muss ich aber 
erst Texte am AES schreiben und auf 
Disketten speichern (mit Textfiles ist die 
Formatanalyse viel einfacher, als mit den 
Systemdisketten). Vielleicht können sie das 
Format analysieren und finden einen Weg, 
es wieder auf Disketten zu schreiben." 


(Zitat von Günther am 24. Sept. 2020). 


Damit war der Start eines neuen Projektes 
geboten. Gemeinsam mit Günther wollte 
ich ein Kopiersystem für die hartektorierten 
AES-Disketten (16 Sektor FM) bauen. 
Günther und ich haben das Projekt 2020 
gemeinsam begonnen, mit dem Ziel die 
AES-LANIER-Disketten kopieren zu 
können. Das ist 2021 gelungen. Im Projekt 
hat Günther die Logistik, also die Beschaf- 


fung und Verteilung von FLUXTEEN-Plat- 
inen, die Organisation und die Tests auf 
dem Zielsystem übernommen. Mein Part ist 
das Design der Hardware, Programmierung 
der benötigten Tools, sowie grundlegende 
Tests. Da wir nun den Leistungsumfang er- 
weitert haben, war es auch nötig, andere 
User mit einzubinden. Ich bedanke mich an 
dieser Stelle bei allen Mitwirkenden herz- 
lich und hoffe auch in Zukunft auf 
tatkräftige Unterstützung. 


Die AES Textverarbeitungsanlage 
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Für das Jahr 2022 sind weitere Entwick- 
lungen und Verbesserungen geplant: 


Ausweitung der Diskettenformate 
auf 3.5", 5.25" und 8", DD und HD, 


sowie FM, MFM, MMFM und GR,  Ve'folgen. 

Hard- und Softsektor j 

Erstellung von D80- und D82- Links 

Imagefiles für CBM Disketten https://forum.classic-computing.de/ 
Erweiterung von FLUXKRYO- forum/index.php ?thread/23170- 
CONV in Richtung FLX-Files zu fluxcopy-projekt-F%C3%BCr-hard-und- 
KRYO-Files. Das würde eine An- software-zum-kopieren-von-hard- 


bindung auch an HxC ermöglichen. ee Beer 
Sobald die FLUXCOPY Versionen RS MOTENERISSSIESOMDENNT IE 
ng forum/index.php ?thread/23989-xy- 
i B ; software-r% C3%A4 
der Erweiterungen ändern, wird es tselungel% C3% B6st/ 


eine ausführliche Dokumentation &postID=295213#00st295213 


sich nicht mehr dauernd aufgrund 


dafür geben. 


Weitere Informationen zum FLUXCOPY 
Projekt, sowie die Downloads der letzten 
Versionen finden sich im Forum (siehe 
Links). Es lohnt sich also, regelmäßig 
vorbeizuschauen und die Entwicklung zu 


TEENSY is a trademark of PJRC.COMLLC 
KryoFlux is a registered trademark ® of KryoFlux GmbH. 


Fundstücke aus der 
LOAD Fernschreibmaschine 


Nachricht von Bender +++ 31.12.2007 

Ein Glück, das der Mensch lesen kann, 

wie wäre es mit einem Vereinsmagazin? 

Nichts monatliches, aber etwas was 4x 
im Jahr dem Rest der Welt zeigt, um was 
s hier geht. Berichte über Treffen, 


+++ Nachricht von Blader +++ 06.03.2012 
+++ Der Launch unseres neuen Magazins 
steht kurz bevor. Es wird den Namen 
"LOAD" tragen. "LOAD", das ist der Name, 
der bei jedem klassischen Computer ein 
gängiger Begriff ist, steht er doch für 
das Laden eines Programms oder eines 
Spiels. +++STOP+++ 


neue Techniken und Produkte, Interviews 
usw. Wer mag kann sich sowas mal am 19ten 
anschauen, das ist nichts 
professionelles, aber mit Freude und 

Begeisterung für die Sache gemacht. +++ 
STOP+F++ 


+++ Nachricht von Kangaroo MusiQue +++ 
20.01.2012 +++ Das VzEkC-Magazin - Gäbe 
es für sowas Autoren der 
unterschiedlichen Systeme, damit man 


+++ Nachricht von Hexagon +++ 18. Juli 
2013 +++ Hab 2 Paletten voll Magazinen 
hier. Jetzt geht's los. +++STOP+++ 


+++ Nachricht von yalsi +++ 18. April 
2017 +++ Die 3.Ausgabe unseres 
Vereinsmagazins LOAD ist erschienen. Es 
handelt sich um eine Online-Ausgabe, die 
ihr auf der Homepage downloaden könnt. 
Vielen Dank von mir an die fleissigen 
Autoren. Euch allen viel Spaß beim Lesen. 


Inhalt bekommt? Partybericht von der 

inen oder anderen Party. Spieletests, 
Vorstellung einzelner MItglieder und 
deren Sammlung oder besondere 
Aktivitäten, Terminkalender für Retro- 
Börsen, Parties (Partys) etc. +++STOP 
+++ 


+++ Nachricht von Blader +++ 01.03.2012 
+++ Ich will nicht zu viel verraten, 
aber ich kann sagen, dass die erste 
Ausgabe eine sehr interessante Auswahl 
an Themen beherbergen und überraschend 


t++STOP+++ 


+++ Nachricht von yalsi +++ 2. Februar 
2018 +++ In den letzten Monaten wurde 
fleissig an der LOAD#4 gearbeitet. 
Autoren aus dem Verein haben Artikel 
geschrieben, das Layout wurde entworfen, 
ein Titelthema festgelegt, über eine 
Druckausgabe nachgedacht usw. Zwar steht 
die Finanzierung noch nicht endgültig, 
aber es besteht durchaus Hoffnung, in 
diesem Jahr durchaus wieder eine 
Druckausgabe herausgeben zu können. 


umfangreich sein wird. Ideen sind mehr 
als genug vorhanden - auch für die 
zukünftigen Ausgaben. (..) In gerade mal 
einer Woche haben wir die Struktur des 
Magazins ausgearbeitet und es sind schon 
fast 3/4 des Magazins mit Inhalt gefüllt. 
+++STOP +++ 


EX EEE TELEX EEE TELEX EEE TE 


t++STOP+H4 


Übersicht zu allen bisher erschienenen 
Ausgaben unter 

https: //www.classic-computing.org/ 
load-online/ 
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Bild oben: CBM PET im Einsatz 
4 Bild Mitte: ‚ Die Reparaturecke hatte viel zu tun 
Bild unten: Das Lokalfernsehen war ebenfalls zu Gast 


Vorschau 


Das bringt 
LOAD#9 


LOAD 


Betriebssysteme 


AmigaOS, TOS, MacOS und Windows kennt 

1 jeder — aber wir stellen Systeme wie BeOS, 
Coherent UNIX, SymBOS oder OS-9 vor und 
geben Tipps für die Installation auf 
verschiedenen Plattformen. 


20 Jahre VzEKC e.V. 


Ende November 2003 fanden sich im Gasthof eines kleinen 
Kurorts im Landkreis Calw in Baden-Württemberg zwölf Retro- 
computer-Begeisterte zusammen, um ihr liebstes Hobby besser 
zu organisieren. Daraus ist heute ein Verein mit über 300 
Mitgliedern geworden, in dessen Diskussionsforen sich über 5.000 
Fans alter Rechner tummeln. Das 20-jährige Jubiläum bietet 
Gelegenheit für einen Rückblick und hält einige Überraschungen 
bereit. 


Jubiläumsjahr 2023 


Der Commodore 64 feiert 2023 seinen 40. Geburtstag, der PET 
wird 45 Jahre alt und WANG Computer feiern ihr 50. Jubiläum. 
Anlass genug, die Geburtstagskinder ausführlich zu würdigen. 


RaSCSI 


Mit einer Zusatzplatine wird der Raspberry Pi zu einer SCSI 
Festplatte mit vielen Goodies. 


Die erste Maus 


Wir erinnern an die erste Rollkugel-Maus, eine Entwicklung aus 
Deutschland. 


..und außerdem: 


MFM-Emulator, Apple-1 Mysterien, Neues aus der Retro- 
computing-Szene, Hintergründe, Portraits, Interviews, Berichte 
und Spieletipps. 


LOAD#9 
erscheint im Frühjahr 2023 


www.classic-computing.de 
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Rechteinhaber zweifelsfrei zu identifizieren und anzuschreiben. Bitte 
wenden Sie sich gegebenenfalls an die Redaktion. 


Preis 

Das Magazin LOAD wird in gedruckter und elektronischer Form 
grundsätzlich kostenlos abgegeben. Um einem Missbrauch 
vorzubeugen, kann die ausgebende Stelle für gedruckte Hefte eine 
Schutzgebühr in Höhe von 3,- EUR erheben. 


Alte Computer verständlich gemacht 
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DAS VEREINSMAGAZIN 


LOAD ist das Magazin des Vereins zum Erhalt klassischer Computer. LOAD ist eine Zeitschrift für 
Retro-Liebhaber, die sich für Homecomputer, Workstations oder klassische Spielekonsolen und 
deren Software interessieren. Egal ob Hardware, Spiele, Anwendungsprogramme, Artikel über längst 
vergessene Computer oder News und Berichte aus der Retro-Szene, all dies macht das Magazin 
interessant für jeden Leser, der sich mit den Themen Retro-Computing und Retro-Gaming beschäftigt. 
Das Heft wird vollständig von den Vereinsmitgliedern gestaltet - wir schreiben Artikel, machen das 
Layout, erstellen die Druckvorstufe und übernehmen die Verteilung des fertigen Hefts. 


IT 
Computer 


LOAD ID 


Hardware 


LOAD#1 


Unsere Erstausgabe. Viele 
Berichte über Homecomputer, 
die im Jahr 2012 ihr Jubiläum 
gefeiert haben. 


LOAD#2 


Viele Details und 
Hintergrundberichte über 
Computer in der DDR, 
außerdem „Die Acorn Story“ und 
vieles andere mehr. 


LOAD#4 


Neue und klassische Hardware 
für Homecomputer, 
Selbstbauprojekte und 
Vorstellung klassischer 
Computer. 
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LOAD#5 


Emulation auf alter Hardware- 
wie sich mit Atari, Acorn, Amiga, 
CBM und Co. neue Welten 


LOAD#6 


Grafische Benutzeroberflächen 
erobern den Alltag: Macintosh, 
AMIGA, Atari — und ihre 


LOAD#7 


IBM PC Geschichte, 
Betriebssysteme, Modelle, 
Olivetti M24, Netzwerke, HP- 


eröffnen. Gegenentwürfe wie Canon Cat Interface Bus, Sinclair Spectrum, 
oder Sinclair QL TheVC20, Assembler, Spielen 
auf dem Würfel-Mac 
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klassischer Computer 


Der VzEkC e.V. ist Deutschlands großer Retrocomputer-Vere n 
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klassischer 
Computer e.V. 
Stephan Kraus 
(1. Vorsiztender) 


Am Schloßgarten 
25/1 

74743 Seckach- 

Großeicholzheim 


Einzelhefte gibt es 
online vorbehaltlich 
der Verfügbarkeit 
gegen eine Spende 
von EUR 3,- zzgl. 
EUR 2,- für Porto 
und Verpackung 
unter 

https://www. 
classic- 
computing.org/ 
get-load5/ 


Folgende Shops 
haben die LOAD 
ebenfalls im 
Angebot: 


Poly.Play: 
https://www. 
polyplay.xyz/ 
Magazine 


ACP&TCP 
Andreas Magerl 
https://www. 
amigashop.org/ 
index.php? 
cPath=44 


Außerdem ist die 
LOAD auf vielen 
Retrocomputing- 
Veranstaltungen 
erhältlich, zum 
Beispiel hier: 


Lange Nacht der 
Computerspiele 
Leipzig 


Alternatives 
Computer- 
meeting 


Retro Computer 
Treff Nieder- 
sachsen 


Classic 
Computing 2022 


Vintage Computer 
Festival Berlin 


DAS FACHMAGAZIN RUND UM DEN AMIGA 


